Sorry, I meant constrain
And I had misunderstood: I thought strings in the dependencies table were being edited (appended to)
Can we make this “Including static values…” rather than “fields”?
1 Like
I think Mixed static and dynamic project metadata needs the word fields in it somewhere since we already have mixed static and dynamic project metadata – a static license with a dynamic list of dependencies would fit that definition.
Okay, one more poll, taking the top two with suggested modifications (and one with both suggestions, sort of), and adding two more based on feeding the proposal text to an LLM and seeing what it thought the title should be (loosely based on two of the suggestions, modified them quite a bit)
- Including static values in dynamic project metadata
- Including static values in dynamic project metadata fields
- Mixed static and dynamic project metadata fields
- Static base values for dynamic project metadata
- Partial static specification of dynamic project metadata
0
voters
1 Like
Is anything else needed here? I’ve changed the title to match the poll results.
If you think the discussion has run its course and the PEP is ready, you can ask Paul as PEP delegate for pronouncement.
In the rejected ideas, it says:
Special case some fields without adding dynamic
This has come up specifically for the pinning build dependency use case, but could also be applied to more of the use cases listed. This would not cover all the use cases seen, though, and an explicit, opt-in approach is better for static tooling.
What are examples for tools that need these fields to be static? (I may have missed this in a previous thread). As a tooling author, I can see that name, version and dependencies (resolver) as well as license (license checker) matter. As build backend author, I have e.g. feature requests to automatically add classifiers, and it seems inconvenient having to teach users about dynamic = ["classifiers"] first. Similarly, import names and entrypoints could be generated in some cases.
Specifically for file inclusions (readme and license files), it would be very helpful to be able to change paths, such as ../../file.md to file.md, to support workspace layouts.
I think that would need to be its own PEP? (And special casing fields was a hard no for license - it would have been nice if a build backend could extend the licenses with AND if it is building a wheel with bundled dependencies, but that had to be removed. So I’m not sure if such a PEP would make it.) This PEP already is a huge win for this sort of thing, as now you can do it, just with the explicit opt-in. Maybe that’s enough?
As a build backend author, you can now say "If you’d like to insert some useful classifiers for you, just add "classifiers" to the dynamic=[] list. You’d want some opt-in/opt-out mechanism anyway, so that does give it to you, it’s just stuck at opt-in vs. opt-out.
I wonder if a dedicated workspace PEP would be useful? Now that Hatch and uv have workspaces, maybe we have enough examples to develop something standardizable?
My question was more, if we’re already doing a PEP that relaxes the rules for those fields, why don’t we go a step further and remove the requirement for dynamic for a number of these fields? Is there anything that relies on this data being static? I find it hard to explain to users why you’d need to set dynamic = ["classifiers"] at all, it creates boilerplate and an unintuitive build backend experience; You need to opt-in to features that build backends will want to provide by default. Specifically, I’m talking about for the fields that are not name, version, dependencies or license (probably license-expression, if it includes license-files that would be unfortunate, that requires checking with license scanners how they work; I can do that checking if that’s required).
For workspaces, I agree that’s a different story and deserves its own PEP, there’s a number of interesting questions attached (e.g., can we share constraints across the workspace, can we share metadata across the workspace, what are the allowed workspace layouts, …)
1 Like
I’d leave it as is. There is no real reason to make something as trivial as classifiers dynamic, and as PEP 621 explains static is preferred for all fields. And as a backend author, I also have very little interest in supporting all fields as dynamic.
2 Likes