A lot of users don't want to structure their projects as valid Python packages -- perhaps they're creating a web application, or a collection of scripts, etc. These all can be structured as valid Python packages, but users tend not to do this. Requiring that projects are valid Python packages makes it harder for existing users to adopt uv.

Today, we allow "virtual projects" (i.e., without a build system) for workspace roots, but only for workspace roots.

This has several issues...

1. It has to be a workspace, you need [tool.uv.workspace] which is confusing for users.
2. It only supports dev dependencies, also confusing for users.
3. There's no way to define project metadata which is confusing for users since they expect a [project] table. For example, there's no way to define a required python version in a "virtual project" (i.e., a virtual workspace root with no members).
4. There's (easy) no way to transition between the two. To convert a non-virtual pyproject.toml to virtual, you have to remove basically everything, move things around, etc.

What I want to do is, allow users to set:

[tool.uv]
virtual = true

If set, they can have a [project] table, they don't need a workspace definition, etc. And in this case, we don't build or install the project, just like a virtual workspace root today.

In the future, we'd like to write our own build system that handles these cases better by default. But for now, this will help a lot of users.