Hatch environments support PEP735 dependency-groups

[djcopley]

Closes #754
Closes #1852

[funkyfuture]

thank you for your effort on this. i left a few notes regarding the user documentation and hope to find some time soon for a deeper look.

maybe the PA's usage guide reg. the dependency groups could also be linked somewhere: https://packaging.python.org/en/latest/specifications/dependency-groups/

[funkyfuture]

i can imagine that a completely reflected use-case would be preferable here. i don't know the current affairs reg. user documentation guidelines, maybe @lwasser has some advice.

[funkyfuture]

i don't really get what this wants to tell me; it seems to be suited for a sentence or two outside the example snippet.

[djcopley]

Yeah I'll remove it. The point I was trying to make is that the project.dependencies (in this example, requests) will be included in the environment if the environment is not configured with "skip-install = true" or "dev-mode = false" but it's just confusing as-is.

[funkyfuture]

if the point here is to point out that dependency groups are no direct project dependencies, i think that aspect can be included in one of the prior paragraphs.

[flying-sheep]

Dependency groups exist to be exactly what hatch’s env dependencies are, so I don’t like the indirection of making an env refer to dependency groups to install.

I think we should do more that simply support them, we should actually integrate them: #1852 (comment)

So I propose that we change hatch to actually collect the list of defined dependency groups and merge it with the list of hatch envs (each dependency group implicitly defines a hatch env, and each hatch env implicitly installs its corresponding dependency group). @ofek should weigh in here.

Imagine: if dependency groups would have existed when designing hatch, would they be used like I propose? I think yes.

[schlich]

@ofek have you put any further thought into this? I was VERY suprised to find out that Hatch did not support this PEP and was thus incompatible with uv and pixi, as others have mentioned. I would be happy to contribute if it is labor that is blocking this; if it's more of an administration, your thoughts on whether or not this will be something that Hatch plans to support would be very appreciated!

[Midnighter]

Greetings all,

I want this feature very much in hatch. I'm willing to put in the necessary work like others above, but that does not seem the blocker here. In any case, please let us know how we can contribute.

[lwasser]

Hi friends 👋🏻 it would be really helpful to include this PR in a future release if possible! We are using both development and optional dependencies in our packaging template. Being able to define dependencies and development devs in a standard TOML format that is not Hatch specific, but then use those in Hatch environments, would make the user experience much simpler and smoother as they learn about and use dependencies!

[djcopley]

I have some free time to work on this this week. It seems like this hasn't had any sort of resolution. I personally am a fan of the current implementation, but feel free to weigh in. I think it would be great to get this merged.

[ofek]

Please describe the current implementation at a high level as well as a brief description of the comment you mentioned. This needs to be rebased as well. I plan to merge this by Monday right after #2073.

[cjames23]

So I propose that we change hatch to actually collect the list of defined dependency groups and merge it with the list of hatch envs (each dependency group implicitly defines a hatch env, and each hatch env implicitly installs its corresponding dependency group). ofek should weigh in here.

Explicit is better than implicit. I do not think it is the right approach to make these implicit mappings. Implicit mappings like this become brittle over time and prone to breakages from changes.

[Midnighter]

Explicit is better than implicit. I do not think it is the right approach to make these implicit mappings. Implicit mappings like this become brittle over time and prone to breakages from changes.

I fully agree with this. Additionally, I want to be able to use dependency groups much like extras/features today. That means, I want to define custom environments where I choose one or more groups of dependencies.

[djcopley]

@ofek rebased.

Please describe the current implementation at a high level

This PR integrates PEP 735 dependency groups into hatch environments similarly to the existing "features" (optional dependencies) implementation. Users can specify an array of dependency groups to compose requirements for a hatch environment.

high level as well as a brief description of the comment you mentioned

@flying-sheep was advocating for an alternate behavior where dependency groups would be treated as de facto hatch environments. For example, a doc dependency group would implicitly be a hatch environment. It isn't how I personally want to use this feature, and I prefer an approach that allows me to organize my dependency groups orthogonally to my environments; however, I don't want to straw-man his argument so I recommend reading the last 2 or 3 comments in that thread if you have time.

[flying-sheep]

I’m totally fine if you don’t go this route. I get now that some dependency groups might only exist as a building block for others (which in turn define a full environment for some purpose), and there is no way to know which are which, so automatically defining a hatch env for every group doesn’t make sense.

[cjames23]

@ofek these changes look good to me. I think once the branch conflicts resolution is done we can merge this as well and maybe release this and workspace environments at the same time.

Thanks everyone for the patience while Ofek and I worked through the PR for workspace environments!

[djcopley]

@ofek this is up-to-date