Add support for virtual projects

[charliermarsh]

Summary

The basic idea here is: any project can either be a package, or not ("virtual").

If a project is virtual, we don't build or install it.

A project is virtual if either of the following are true:

• tool.uv.virtual = true is set.
• [build-system] is absent.

The concept of "virtual projects" only applies to workspace member right now; it doesn't apply to path dependencies which are treated like arbitrary Python source trees.

TODOs that should be resolved prior to merging:

• Documentation
• How do we reconcile this with "virtual workspace roots" which are a little different -- they omit [project] entirely and don't even have a name?
• uv init --virtual should create a virtual project rather than a virtual workspace.
• Running uv sync in a virtual project after uv init --virtual shows Audited 0 packages in 0.01ms, which is awkward. (See: Improve messages for empty solves and installs #6588.)

Closes #6511.

[charliermarsh]

Unfortunately, we do need to set an explicit build backend for our test projects now. This is fine and correct, we were just omitting it before.

[charliermarsh]

This needs documentation.

[charliermarsh]

I wonder if we should use different terminology here to differentiate from a "virtual workspace root".

[charliermarsh]

We might be better off with a concept of "applications" vs. "libraries" here?

[charliermarsh]

Or, even better, we remove virtual workspace roots entirely.

[charliermarsh]

I feel pretty good about this apart from the use of "virtual" here and the fact that a "virtual workspace root" is slightly different.

[mkniewallner]

"virtual" seems a bit abstract to me, and not really self-explanatory about what it does.

Some background on this:

• PDM uses a distribution boolean
• Poetry uses a package-mode boolean

From those two, I find Poetry's one to be a better fit, as "distribution" seems like this is only about preventing publishing a package.

What about using something a bit more explicit like project-type that could either be application or package (or library)? I personally find those concepts closer to what people are used to when creating Python projects. Using an enum also make it possible to add more values in the future (although I don't really see what else we could have).

[charliermarsh]

My preferred framing here is application vs. library (in Rust it’s “binary” vs. “library”), but curious to hear from @zanieb on it when they’re back.

[a-reich]

IIUC, [project] still must have name and version for virtual projects/applications - does it make sense to make them optional?

[charliermarsh]

No, I still plan to require those. Otherwise, it’s not clear how to identify a given package in the lockfile.

[a-reich]

Hmm ok, I guess I misunderstood the mental model, as it hadn’t occurred to me that a project was allowed to depend on an application.

[charliermarsh]

Just depends on the semantics we want to allow!

[philgyford]

No, I still plan to require those. Otherwise, it’s not clear how to identify a given package in the lockfile.

Fair enough if there’s no technical way around it, but it feels very odd to require it for something like a website.

Even on my solo, personal sites I might commit and deploy several times a day, and having to decide on a version number every time (and remember to change it) would be a real pain.

[z3z1ma]

Even on my solo, personal sites I might commit and deploy several times a day, and having to decide on a version number every time (and remember to change it) would be a real pain.

You dont need to. Set the fields once in pyproject toml. Since you are not building a package with a build backend, the values are moot. Just use them as metadata for your app.

[sersorrel]

I'm not sure that the "library"/"application" framing necessarily corresponds well to "should/should not be installable". You want a library to be an installable package, so that it can be depended upon; but you also (sometimes?) want an application to be an installable package, so that you can install and run it (say, pipx install uv).

[minkooseo]

What about "non package" or "not a package" then? Not sure if it's a good flag name, but it's something we can use to explain what this is about. It's also a term used in #6578.

Coming from the experience of always putting sources at the top, 'git push' and then 'git pull' at the server to serve web traffic, it was quite new to me that I should put code under src/project_name. I learned that I build a package and publish it that way, and I can create a package and install it on the server.

It is still a project for me, so I was searching the doc to understand what's a project then if mine is virtual. (I still don't know)

It is an application and not a library, but it is now clear to me that application can still be an installable package. It may create confusion for people with knowledge.

[charliermarsh]

That's actually what we're using in this PR. The flag is package = false etc.

[zanieb]

@minkooseo might be helpful to look at #6689 too, but we're going to push out a bunch of changes around this soon.