Amazing to see PEP-735 so fast! And cool of you to adopt it immediately for dev dependencies. You are doing great things 🙂
One of the motivating use-cases for the PEP was science/data science projects that need to specify dependencies but aren't packages. One reason being that a [project] table needs a name and a version which can is a bit weird in that context. Another was the attitude of some of the Python devs that project.dependencies] should only be used by things that get packaged and not as an alternative to requirements.txt.
The PEP envisages for this use-case that the pyproject.toml file wouldn't contain a [project] table at all but instead just a [dependency-groups] one containing a main group.
I'm curious - have you guys considered supporting this exact scenario? By this I mean doing the following:
Syncing a dependency-groups.main by default if present, i.e. special casing it in the same way as you have decided to do for dependency-groups.dev (which is a nice move by the way)
Adding a dependency to dependency-groups.main if uv add is run on a project whose pyproject.toml doesn't contain a [project] table
Creating a pyproject.toml that matches this setup for some new kind of project distinct from --app, --lib, and --package
This new project type would also be very much applicable to e.g. a folder of random scripts where the user wants to maintain a common set of installed packages and nothing more (this is something I'd use it for, on top of for scientific projects). At the moment this is still best managed using uv venv and uv pip.
I don't know what this new project type would be called. "Workspace" would have been fitting but now has a different meaning. "Environment" is honestly not wrong as a way of describing the concept but has so much baggage (uvenv anybody? Lol). Maybe a "directory". My best suggestion would be "minimal" or "bare", the latter of which I particularly like. But no idea really.
The closest project type currently is --app but neither its behaviour nor its name quite feel like a good fit for the science use-case or the other I mentioned. So this would help with that too perhaps.
If you were to implement something like this, I also think it'd be worth making "bare" the default project type of uv init without flags, as I think the people who are most likely to want this kind of minimal behaviour are also probably the ones least knowledgeable about Python project management. But that's a separate point tbh.
I'll return to this, but in brief we're pretty interested in supporting this use case and, more generally, we'll be able to support dependency groups without a [project] section soon.
Amazing to see PEP-735 so fast! And cool of you to adopt it immediately for dev dependencies. You are doing great things 🙂
One of the motivating use-cases for the PEP was science/data science projects that need to specify dependencies but aren't packages. One reason being that a
[project]
table needs a name and a version which can is a bit weird in that context. Another was the attitude of some of the Python devs thatproject.dependencies]
should only be used by things that get packaged and not as an alternative torequirements.txt
.The PEP envisages for this use-case that the
pyproject.toml
file wouldn't contain a[project]
table at all but instead just a[dependency-groups]
one containing amain
group.I'm curious - have you guys considered supporting this exact scenario? By this I mean doing the following:
Syncing a
dependency-groups.main
by default if present, i.e. special casing it in the same way as you have decided to do fordependency-groups.dev
(which is a nice move by the way)Adding a dependency to
dependency-groups.main
ifuv add
is run on a project whosepyproject.toml
doesn't contain a[project]
tableCreating a
pyproject.toml
that matches this setup for some new kind of project distinct from--app
,--lib
, and--package
This new project type would also be very much applicable to e.g. a folder of random scripts where the user wants to maintain a common set of installed packages and nothing more (this is something I'd use it for, on top of for scientific projects). At the moment this is still best managed using
uv venv
anduv pip
.I don't know what this new project type would be called. "Workspace" would have been fitting but now has a different meaning. "Environment" is honestly not wrong as a way of describing the concept but has so much baggage (
uvenv
anybody? Lol). Maybe a "directory". My best suggestion would be "minimal" or "bare", the latter of which I particularly like. But no idea really.The closest project type currently is
--app
but neither its behaviour nor its name quite feel like a good fit for the science use-case or the other I mentioned. So this would help with that too perhaps.If you were to implement something like this, I also think it'd be worth making "bare" the default project type of
uv init
without flags, as I think the people who are most likely to want this kind of minimal behaviour are also probably the ones least knowledgeable about Python project management. But that's a separate point tbh.