Support for PEP 735: Dependency Groups in `pyproject.toml`
This PEP was just accepted — we plan to support it. We'll track it here.
The implementation can be tracked in https://github.com/astral-sh/uv/pull/8272
I'm just curious, but will there be a "dev" dependency group that supplants
[tool.uv]
dev-dependencies = …
or is it up to the user to specify the group= when running uv sync?
Dependency-groups don't allow self-dependencies, so dev-dependencies = ["<self>[test]"] wouldn't be replaceable with dependency groups. Also, I think/hope that dependency groups are going to feed into a new environment and task system. :)
I noticed there is no mention of constraints in the pep. Dev-constraints is super useful to me . Do you think this concept will continue to be supported as 735 is implemented?
On Fri, Oct 11, 2024, 20:34 Henry Schreiner @.***> wrote:
Dependency-groups don't allow self-dependencies, so dev-dependencies = ["
[test]"] wouldn't be replaceable with dependency groups. Also, I think/hope that dependency groups are going to feed into a new environment and task system. :) — Reply to this email directly, view it on GitHub https://github.com/astral-sh/uv/issues/8090#issuecomment-2408333294, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABY5SZNHP7RTAJMIFAHFSW3Z3CKEHAVCNFSM6AAAAABPW2Q3ESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGMZTGMRZGQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Dependency-groups don't allow self-dependencies, so dev-dependencies = ["
[test]"] wouldn't be replaceable with dependency groups.
Is this explicitly banned? I think group = ["my-project[test]"] might "just work" in uv because of how we treat package names that are shadowed by the project?
will there be a "dev" dependency group that supplants ...
I'm not sure yet. This is a significant open question I must address before adding support.
I noticed there is no mention of constraints in the pep...
I don't see any reason that we wouldn't apply constraints to the dependencies in the groups. Do you need a separate set of constraints?
I only see this section, but I don't see any other discussion in the finalized PEP of self-references of project dependencies in dependency groups.
I noticed there is no mention of constraints in the pep...
I don't see any reason that we wouldn't apply constraints to the dependencies in the groups. Do you need a separate set of constraints?
I am asking about the equivalent of constraint-dependencies, which I don't see addressed. I have a similar use case as discussed https://github.com/astral-sh/uv/issues/6518 . We use a managed airflow service. For dag development we only need a subset of the installed py dependencies and installing every py dependency is challenging and overkill because it requires several system dependencies. I'm slowly converting people to use uv, one of the motivations is having an easy, declarative approach to setting up a virtual environment for development.
here is an example from pyproject.toml from a repo that contains dags:
[tool.uv]
dev-dependencies = [apache-airflow[gcp,beam]==2.9.1]
constraint-dependencies = [ long list of transient dependencies from cloud composer docs]
cloud composer docs I want to install what i need but I want to make sure I don't install a transient dependency with a different version from our prod environment.
1 difference from the other issue is we are not using the official airflow constraints file from the url (this is what i used to use before we moved to the managed airflow). Right now I am copying the list of installed packages into my pyproject.toml file.
@dschneiderch -- Apologies if I'm misunderstanding but I think constraint-dependencies will just continue to be the right thing to use there.
Perfect! Wasn't sure if that metadata field was going to be redesigned alongside dev-dependencies .
On Sat, Oct 12, 2024, 14:02 Charlie Marsh @.***> wrote:
@dschneiderch https://github.com/dschneiderch -- Apologies if I'm misunderstanding but I think constraint-dependencies will just continue to be the right thing to use there.
— Reply to this email directly, view it on GitHub https://github.com/astral-sh/uv/issues/8090#issuecomment-2408699012, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABY5SZLLZYROQTHBXX5QSVLZ3GE7HAVCNFSM6AAAAABPW2Q3ESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGY4TSMBRGI . You are receiving this because you were mentioned.Message ID: @.***>
Duplicates https://github.com/astral-sh/uv/issues/5632 -> either this or the other one could probably be closed.
Would love to get it in ... PR is coming I see :)
Same, looking forward to using it in the Airflow repo
@jankatins thanks! Embarrassing I keep creating duplicates of my own issues. I'll close them both when we add PEP 735 support.
@jankatins thanks! Embarrassing I keep creating duplicates of my own issues. I'll close them both when we add PEP 735 support.
With the speed you are all working, occasional duplicate is not embarassing, it's a given :D. You are all doing great job.
As of 0.4.27 we support this. Details in #8272.