Support --unsafe-package in uv pip compile

[hauntsaninja]

pip-compile has this flag that's a useful escape hatch. There's some software we use where we care about the specific build. We don't want the build from the index and we don't want it in our lock file, we want to manually manage how it gets installed.

[kummerer94]

Strong +1 for this feature.

To add another usecase: If you develop on Windows and run uv pip compile ..., you will sometimes have dependencies in your output file that are only necessary for Windows (like pywin32).

Now, I understand that cross compilation is a problem itself (see here) and pip-compile itself does not solve it. But --unsafe-package gets you very far without having to go through the hassle of creating different requirements.in files.

[zanieb]

Can you share a bit more about the workflow for this?

[hauntsaninja]

Sure! So one of the packages for which we care about the specific build is torch. Now we have some service that's a Python package that has torch in its dependencies. We run something that basically boils down to something like pip-compile package/pyproject.toml --unsafe-package torch --generate-hashes -o requirements.txt to produce a lock file that does not contain torch. When building the deployment, we pip install --no-deps -r requirements.txt and then do some custom thing to install the specific build of torch we want for that deployment.

This is not a critical feature in that we could be unblocked by writing a wrapper script that parses requirements.txt and removes the packages we don't want from it, but it is something pip-compile currently supports

(This is a thing that maybe sounds like it could be solved by using a custom index or maybe by using URL requirements, but neither of those really works for us in practice)

[hmc-cs-mdrissi]

I originally contributed unsafe-package to pip-compile mostly as an escape hatch. My main use case was handing multiple editable installs. I work in monorepo with several libraries. My requirements.in looks like this,

-e file:lib1/
-e file:lib2/
...

and I pip compile that with pip-compile requirements.in --unsafe-package lib1 --unsafe-package lib2. This allows resolving dependencies of repository with hashes but without editable requirements. Afterwards we then do pip install --no-dependencies requirements.txt && pip install --no-dependencies requirements.in.

pip requirements.txt does not support a dependency with hashes + editable dependency in same file. This is open issue. For my specific usage if requirements.txt file could support both hashed non-editable dependencies and editable dependencies together then I probably wouldn't use it. The feature was made as broader escape hatch though mostly because it was easier. pip-compile already had a few packages marked unsafe by default (setuptools/pip), so extending that logic to user custom unsafe was straight forward.

edit: Name unsafe only comes from it being based on default unsafe packages that existed for many years prior. A more obvious name might be --output-exclude-package (or maybe brief --exclude-package). Here exclusion applies only to output requirements file made. The package is still used as normal during resolution time.

[gilfree]

If I might add a use case - some packages depend on non-python stuff. For example, cupy depends on cuda. It uses naming scheme like cupy-cuda12x.

We pip compile our requirements, to pinned dependencies of such packages, but as we have multiple cuda versions we work with, we have a later command that checks the cuda version and installs the relevant package.

We want to have the dependencies of these packages to be pinned and be included in the generated requirements package, but we can't have these cuda-versioned packeges there.

Having a flag that says - "omit cupy from the generated file" will be great. (We can solve this by post processing the requirements file, but I think it will be safer to have this explicit)

[charliermarsh]

I will add.

[charliermarsh]

I'm tempted to use a different name but...

[charliermarsh]

If anyone has suggestions, feel free to share, though I reserve the right to just go with --unsafe-package and move on :)

[charliermarsh]

Actually, I'll likely at least use --unsafe-package for compatibility.

[nathanjmcdougall]

I think --exclude would be a good alias.

[msharp9]

I don't see --unsafe-package in the docs: https://docs.astral.sh/uv/reference/cli/#uv-pip-compile. I don't get an error when I include the flag and I see the PR.

[charliermarsh]

It’s “no-emit-package”.