-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Proposal: PEP 735 "Dependency Groups" Support #12963
Comments
Some questions around the UI. How would something like How will the flag work with multiple requirements? If I do Basically, I don't think we have an existing flag that works like I'd expect this one to, which might be a usability problem. |
I'd consider pip the wrong place for managing this in a normal way IMHO it's different enough from normal install that it warrants a distinct command to install dependency groups of a specific source folder Tools like hatch, rye and poetry should be the place of closer integration |
I am a bit concerned about meeting the target use cases for the PEP without pip support. It would be possible, but the user experience is worse in several cases.
That may be, but I see the feature as similar to
I think the answer here is "and" not "or". Dependency Groups will have the greatest positive impact if they are supported by installers, environment managers, and build backends. I've started with pip and setuptools. Perhaps this is a strategy mistake and I should begin from younger tools like flit. Before I dive into Paul's specific scenarios, I want to start from the high level concern, make sure I understand it, and consider whether or not the UX I proposed is correct.
Is the issue that this is expected to expand to a set of requirements, whereas I'm trying to understand if the issue would be mitigated by making the toml file explicit, e.g., |
I believe the proposed installation ux clearly shows my 3rd point |
I think the problem for me was that it wasn't clear that you're proposing that
If I understand, you're proposing to add a new form here:
This would look in a
That was incorrect, we do, it's There's some background information available in #8049. The conclusion there was that we rejected the feature request, but dependency groups are much more specific, and will be standards-based, so I think it's within scope for pip to support them. Also, there may be some edge cases that won't work, because requirements files are much richer than dependency groups. For example, |
Strong -1 on me for allowing anything but "read dependency groups from |
So one of the repos I work with is a messy monorepo, in that repo we would never put a This has never been a problem because front end and utility tools, like pip, pre-commit, linters, formatters, etc. allow you to specify where you want the configuration / requirements to come from. And backend tools that do not allow this are generally not suitable for the repo anyway i.e. we never want to build a package in the root of the repo. Were pip to use this as a "requirements-like install file but with structured options" it would be a departure from pip's current approach to allow the user to specify the path of the requirements file or constraints file, and other front end tools in general. If you don't consider "messy monorepo" as a valid use case, fair enough, but we're not trying to build a package from it, so it would be annoying for frontend tools, that are not project management tools, to say how we should structure our project. That said, this isn’t a hill I want to die on, just want to give an alternative view point. |
What's the problem this feature will solve?
"Dependency Groups" are proposed in PEP 735 with a variety of target use cases.
In particular, the
--only-deps
use cases are explicitly a target for this PEP, but additional cases are listed and relevant.Describe the solution you'd like
As the PEP author, I would like to start discussing what form, in terms of interface and implementation,
pip
support would take.I would like to agree on a potential implementation path, implement it in a draft PR, and leave it pending until the PEP is accepted.
My proposal is:
pip install
,--dependency-groups
, which takes a comma-delimited list of group names and attempts to resolve and install all of them frompyproject.toml
in the current working directoryFor example,
Would the
pip
maintainers be amenable to this addition? Is there an alternative, similar strategy which I could implement?Alternative Solutions
If
pip
does not gain support for Dependency Groups, it is possible to workaround the gap.Primarily, external tooling like
dependency-groups
can be used to resolve groups and pass them topip
.For example, in a *nix environment, the following usage covers most cases:
However, such usages will always be workarounds.
pip
support provides a superior developer experience.Additional context
PEP 735 is in Draft, and will be submitted soon. At time of writing, it is not final or accepted, but no further changes to the contents are planned.
Code of Conduct
The text was updated successfully, but these errors were encountered: