`uv pip compile` does not include extras in output

[palfrey]

If for example you run echo "celery[redis]" | uv pip compile - then the redis extra is correctly picked up and the extra requirements added to the output. However, the output will contain something like celery==5.3.6, not celery[redis]==5.3.6 and pip-compile does the latter.

uv: 0.1.3

[charliermarsh]

Are there benefits to including the extra? (Asking genuinely, I thought it was fine to omit since it shouldn’t affect installation given that everything is flattened.)

[palfrey]

Debatable. So, in terms of "does this change what gets installed or the actual behaviour of packages", I don't think so. AFAIK packages don't have access to what extras they were installed only, and the only thing they see is "is package X in my extras installed".

In terms of "dev readability/trust", a little bit. If I told a package requirements system like pip-compile to compile a requirements file into a set of concrete requirements, and the extra bit goes away, I'm going to get a bit concerned.

There's an interesting pip-tools issue (https://github.com/jazzband/pip-tools/issues/1613) talking about whether to remove this or not, and that flags a fun case with GDAL doing things depending on the order of installation (https://github.com/jazzband/pip-tools/pull/1608#issuecomment-1087044018)

[SnoopJ]

I personally use pip-compile as a way to record a canonical environment with a complete record of my intent. I guess you can argue that the original metadata is where the intent should live, but I find it helpful that pip-compile preserves the requirement, especially when comparing generated files without referring back to the originating metadata that contains the full story.

In lieu of filing a separate issue, I'll point out on this one that uv pip compile also drops environment makers like sys_platform and python_version, which is aggravating to my own workflow for the same reason: the generated file doesn't record my original intent, only the outcome of resolving my intent in the particular environment that ran the command. I'm not sure if that counts as a bug, actually, since installing files generated by pip-compile can vary across environments because of those markers, even if the expected workflow is that you generate your requirements file per-environment. Happy to file a separate issue if it's just noise on this one.

---

I'd say that if uv decides not to support this behavior of pip-compile (which will continue to exist, because --no-strip-extras allows you to explicitly opt out of the coming change in default behavior), the difference should be documented for unsuspecting users to whom it will matter (👋).

[hauntsaninja]

My 2c: This should certainly not be the default, pip-compile is doing the right thing by changing its default to --strip-extras. This ensures compatibility with constraints files, avoids pip bugs like https://github.com/pypa/pip/issues/9644, etc

[palfrey]

My 2c: This should certainly not be the default, pip-compile is doing the right thing by changing its default to --strip-extras. This ensures compatibility with constraints files, avoids pip bugs like pypa/pip#9644, etc

I'm not too fussed (especially given the possible change in pip-tools) about this being the default or not, provided there's an option to not strip them, which is my personal preference as I'd rather that and live with the possible issues from it. Also, it makes it much easier to use this as a drop-in "no changes in output" option from an existing pip-tools setup, and then maybe change the setting if I hit the issues later on.

[groodt]

One datapoint from me: rules_python (a set of bazel build rules for python), presently supports pip-tools compile lockfiles and it relies on the extras format for constructing the transitive dependency graph. It's possible we will eventually migrate to other other formats (or a standard lockfile if that ever materializes), but in the interim, we would be unable to support uv users (or even directly integrate with uv) without a flag to enable these extra annotations. From a rules_python maintainer POV, we don't mind if they're stripped by default, but it would help a lot of existing users if they could use --no-strip-extras to continue using their locking workflows with bazel, while swapping to uv instead of pip-tools for lockfile generation.

[charliermarsh]

It's probably not too bad to add opt-in support for this. I will take a look.

[kennethreitz]

Thanks @charliermarsh I just used this functionality