Add an initial implementation of PEP 735 Dependency Groups #24
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
resolves #23
This initial implementation takes the form of
dependency-groups
table as aMap<String, Vec<DependencyGroupSpecifier>>
DependencyGroupSpecifier
as a string or an includeThere are a couple of points I'm not certain about. Although I would be amenable to changing these, I might have to defer to someone more expert, as my Rust is pretty weak.
I don't know if it's satisfactory for the table to be defined as a type alias? It seemed like the best fit, but I'm not sure if there's a better way of doing this.
This is within the
SHOULD
/MAY
bounds of the spec, in that tools are allowed to load and validate all of the data eagerly, but the spec also explicitly prefers lazy validation of the table contents.There are a few ways I thought it might be possible to tackle this (e.g., add a branch to the
DependencyGroupSpecifier
enum for aMap<String, toml::Value>
), but ultimately it feels like a good fit for Python and a poor fit for Rust.Eagerly validating the content just seems to me like the most language-appropriate behavior.