Repository navigation
FR: add support for uv pip install <PyPI package> --all-extras #7295
Description
I know of a couple packages with so many optional dependencies that they implement a shorthand to get all of them as, for instance pip install 'pkg[all]' or something similar. Problem is that this is hardly discoverable for end users, must be documented, and not every package chooses the same extra name so it's hard to remember.
uv pip install <PyPI package> --all-extras would seem like a natural solution here but currently (as of uv 0.4.9) doesn't support this:
$ uv pip install astropy --all-extras
error: Requesting extras requires a `pyproject.toml`, `setup.cfg`, or `setup.py` file.Is it something that could be considered in the future ?
Activity
notatallshaw commentedon Sep 11, 2024
Would
--all-extrasalso apply to all the dependencies and transitive dependencies? Or would it be per-package?neutrinoceros commentedon Sep 11, 2024
I think per-package makes more sense.
neutrinoceros commentedon Sep 11, 2024
Actually I'm not 100% I get what you mean by per-package. What I'd like to happen is that everything from the requested package's optional dependencies is installed, ignoring existing their extras. IIUC that would be the same behavior as installing a package from a path with
--all-extras.Does this make sense ?
notatallshaw commentedon Sep 11, 2024
For example, let's say I had a requirements file:
And a constraints file:
And I ran:
uv pip install Eee -r requirements.txt -c constraints.txt --all-extrasWhich packages out of Aaa, Bbb, Ccc, Ddd, Eee, should have requested all extras?
neutrinoceros commentedon Sep 11, 2024
I'd say
Eeefor sure but not sure about the rest. I rarely ever encounter or use constraint files, I'm not sure how to interpretCcc[extra]==1as a constraint. I'm guessing it means thatCcccan only be installed at version1with extras[extra]or not at all ?notatallshaw commentedon Sep 11, 2024
Yeah, ignore the constraints, they don't work well with extras anyway, I was trying to think of unusual edge cases.
IMO the only sensible approach would be to include all user provided requirements, all those provided over the CLI, and all those provided in requirements file, having a flag depend on how you provided non-local requirements would be susprising and not fit with any existing flag I think?
I think
--all-extrascomes from the pip-tools and Poetry world, uv would make it need a decide if this consistently and logically works for them.It might also be a breaking change with the way users currently use it currently? E.g. would this affect
echo -e {local_package}\n{non_local_package} | pip compile - -all-extras?A similiar topic has been on my mind this last week, hence the questions, my idea is about making this easier to define in the
pyproject.toml.neutrinoceros commentedon Sep 12, 2024
Agreed. Anything else would be both more surprising and less maintainable.
Oof, this made me realize I don't know what
--all-extrasmeans for a requirement file. The only way I know how to define the code extras is through pyproject.toml, so, I really don't know.I didn't know self referential extras weren't documented. This is actually what the packages I have in mind (yt and astropy) already use !