Just to note, since I was quoted, I wasn’t necessarily endorsing that aspect of the proposal, just pointing out a more concise alternative syntax for it. FWIW, I don’t use or favor this pattern myself, though it’s already fully possible to do this without this proposal using the current dynamic
.
There’s discussion on the
pip
issue tracker about gaining the ability to install the various groups of dependencies listed inpyproject.toml
.
Err, maybe getting a little OT, but isn’t that perfectly possible right now with pip install -e .[test]
, etc. (except you get the package built and installed too)? Or are you referring to a --deps-only
flag which would enable installing dependency groups (and package deps in general) without installing the package itself, which would replace that use case for requirements.txt
(which is certainly something I’ve missed from using it in Conda, and would very much like to see in pip
)?
My impression so far is that I quite like the core argument @henryiii is making about allowing specifying metadata statically and adding them to dynamic.
To note, this would partially, but not completely address what you’re asking for in the other thread; your backend could add additional requirements, but not alter the specifiersets for existing ones…unless either there was a special case allowing additional specifiers for when SpecifierSet(<modified>) in SpecifierSet(<original>)
, i.e. the modified version specifierset was a subset (i.e. contained within, stricter than) the original—or multiple specifiersets were allowed for the same distribution name key, in which case the intersection was taken (which could potentially result in impossible to satisfy dependencies if the sets are disjoint).