uv.lock ends up in root of site-packages

[bollwyvl]

Prerequisites

• I am using the latest version of Locust
• I am reporting a bug, not asking a question

Description

Congrats on 2.32.10.

The tar.gz and .whl now include a uv.lock which ends up in the root of site-packages.

This isn't a huge problem for pip and friends, which will happily overwrite files, but downstreams can get a little touchy about clobbering files.

On conda-forge, I'm deleting it before install.

Command line

pip install locust

Locustfile contents

-

Python version

3.9

Locust version

2.32.10

Operating system

linux

[cyberw]

@mquinnfd , wdyt?

[mquinnfd]

So we've been doing this for a fair amount of time with poetry.lock - for example

This is mostly to give people a SBOM for what is in their built package specifically.

This is easy to remove, but a couple of things I guess:

• Was this not an issue with the Poetry lock file?
• Can you give a worked example of an issue this causes that I can replicate please?

Perhaps we can tuck it into a different folder somewhere if necessary, it's certainly not mandatory if pip is touchy about the UV one specifically 🤔

[bollwyvl]

As I said, pip et all generally don't care about clobbered files (or [extras] on successive solves, etc.) And poetry also notoriously did this with e.g. multiple LICENSE files until about 1.8.

To observe a problem, one would have to find two misbehaved packages, let's say , locust and grasshopper.

pip install locust
cat .venv/site-packages/uv.lock  # this is from locust
pip install grasshopper
cat .venv/site-packages/uv.lock  # this is now from grasshopper
pip uninstall grasshopper
cat .venv/site-packages/uv.lock  # fails, file is missing

Other package managers, such as conda, apt, etc. would complain about these things when installing grasshopper. Indeed, poetry.lock from locust was also historically getting dropped in site-packages/poetry.lock, and I hadn't caught it in this case, as I hadn't actually shipped locust as part of a more locked-down installer artifact.

As for SBOM: lovely! But starting with what actually ships, a la #2438, in a standard format (e.g. SPDX/CycloneDX) rather than whatever-build-tool is in use would be a lot more accurate. But where to ship this is another story: while CPython has been shipping an spdx SBOM for a while, it's not included in the distribution, and I've yet to see this discussion evolve into a PEP.

[mquinnfd]

I see, thanks for the explanation ---

Would this be an issue for both the sdist and wheel produced?

It's an easy one for us to remove if @cyberw is OK with it, we can toss a standardised SBOM onto the backlog somewhere, I don't think we have people depending on finding the lock file with the tarball currently

(p.s. interesting behaviour generally, I didn't expect that it the top level files would end up in the root of site packages 🤔)

[mquinnfd]

For @cyberw there's a PR to revert this here if you want:
#3055

[cyberw]

Merged that PR. A standardized SBOM somewhere would be nice, but I don't particularly need it, so no rush from my side (we didn't have anything like it before Poetry so apparently we could live for a long time without it :)