Right, and you’re only dealing with a single project, so the extra is unambiguous – got it.
While we’re not yet aligned on the goals, I think there’s sort of a gradient of options being considered here:
- A new
requirements.txt: captures a single scenario, across many platforms. - The PDM-style lockfile from the previous iteration of the proposal. It’d still be focused on a single project, but it would presumedly support installing extras and dependency groups for that project.
- The lockfile in this current iteration, which allows packages to be tagged as part of arbitrary groups, with the intent of supporting multiple roots (e.g., workspaces) in addition to extras and dependency groups.
I find a fourth option (4) sort of intriguing, inspired by Brett’s most recent comments, which is: the standard just covers [[packages]], a flat list of packages, but any metadata connecting the packages or indicating when they should be installed, etc., needs to go in [tool]. That way the standard just covers “listing a set of packages”, which makes it very flexible while still enabling tools like Dependabot to operate on the standardized format. Then, uv, Poetry, PDM, etc. could decide what they want to write in [tool] to support their CLIs atop those lockfiles. And we can continue building out functionality in uv (like locking build dependencies) without being constrained by the standard.
My current opinions are as follows:
- As I said before, if we want to do (1), that seems fine with me. It seems useful to standardize this, even as an export format.
- If we do (2), I would… try to find a way to make it work for uv. Maybe we’d write a separate lockfile for each workspace member? Then we’d be in “the same” position as Poetry and PDM. I think it would be a worse experience for uv users and would create a lot of complexity for us, but I’d still try. (Or maybe we’d find a way to solve this with
tool.uv? I’m not sure.) - If we do (3), I’d push for several changes to the schema, but I’m trying to ignore those for now. I remain worried that (3) is a little too closely coupled to the tools themselves, as per my previous comments… But if we no longer view installer interoperability as a goal, then I think it’s possible for us to align on something here, and I’m game to try.
- If we do (4), that’s also fine with me. In fact it might be my preference, since it seems to nicely balance “the things we want from standardization” with not constraining tools.
Finally, it was suggested above that one outcome here could be that Poetry and PDM use the standard as their first-class formats, but uv just exports to it. Honestly, I’d be really disappointed by an outcome like that, and I think it’d be a big loss for the ecosystem to standardize on something that willing implementers already can’t use today. So, as my comments above reflect, I’m trying very hard to avoid that while still sharing my honest opinions 