search

astral-sh / uv

An extremely fast Python package and project manager, written in Rust.
https://docs.astral.sh/uv
Apache License 2.0
24.24k stars 702 forks source link

Add a project type that uses `[dependency-groups]` only and doesn't define a `[project]` table? Sync `dependency-groups.main` by default? #8582

Open matterhorn103 opened 3 hours ago

matterhorn103 commented 3 hours ago

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:

  1. 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)

  2. Adding a dependency to dependency-groups.main if uv add is run on a project whose pyproject.toml doesn't contain a [project] table

  3. 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.

zanieb commented 3 hours ago

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.