Option to ONLY install extras from pyproject.toml
jordantshaw opened this issue · 4 comments
What's the problem this feature will solve?
Being able to produce requirement files which only contain the extra dependencies in the pyproject.toml file.
Describe the solution you'd like
For a few of my python applications (not installable libraries) I am using pyproject.toml files to define the top-level dependencies. I like being able to define all of the dependencies within the pyproject.toml file, rather than using requirements.in files.
I would like to be able to create a requirements-dev.txt file based off the optional-dependencies in the pyproject.toml, but only the extra dependencies should be in the requirements-dev.txt file.
Extras have a different purpose/semantics. And no installers would install them separately from the mandatory runtime deps. They are exposed to the end-users and are essentially a feature-flag like API. Also, pip-tools is not an installer but a constraint file generator.
What you want is defined as "dependency groups" in PEP 735, which is not yet finalized. I mentioned it in passing in my comment about the locking/pinning misconceptions: #1326 (comment).
@webknjaz I understand what you are saying. I think I solved my problem using using the constraint arg (-c). Basically I am trying to generate a requirements-dev.txt file, but I want to make sure that the pinned dependencies from the requirements.txt file are used. This does what Im looking for.
pip-compile --upgrade -o requirements/main.txt
pip-compile --upgrade -c requirements/main.txt -o requirements/dev.txt --extra=devAs per your comment about using extras in a pyproject.toml file to define dev dependencies. I think you are right, that should not be done in a installable library type project. However, in an application project, where code is simply being deployed, I dont see why you shouldn't define dev dependencies in the extra-dependencies section. As there really is no "end-user" of the application.
I'd like to emphasize that extras are only defined in the context of distribution metadata. Any other use implies a distribution anyway. To address this separate use case, PEP 735 defines dependency groups that aren't going to end up in the distribution metadata and are tailored specifically to the use case you're describing.
Meanwhile, keep having separate requirements files — they're made for this too, the difference is that they are pip-specific and PEP 735 is going to solve this in a generic cross-compatible tool-agnostic manner.