Charlie Marsh 1ecdc1a31e Model groups as a property of requirements (#9545) ... ## Summary Today, our dependency group implementation is a little awkward... For each package `P`, we check if `P` contains dependencies for each enabled group, then add a dependency on `P` with the group enabled. There are a few issues here: 1. It's sort of backwards... We add a dependency from the base package `P` to `P` with the group enabled. Then `P` with the group enabled adds a dependency on the base package. 2. We can't, e.g., enable different groups for different packages. (We don't have a way for users to specify this on the CLI, but there's no reason that it should be _impossible_ in the resolver.) 3. It's inconsistent with how extras work, which leads to confusing differences in the resolver. Instead, our internal requirement type can now include dependency groups, which makes dependency groups look much, much more like extras in the resolver.		2024-12-04 00:55:51 +00:00
..
src	Model groups as a property of requirements (#9545)	2024-12-04 00:55:51 +00:00
Cargo.toml	Align indoc and base64 workspace dependencies with root project (#9555)	2024-12-01 17:20:22 -05:00