As soon as a [project] table is present, a number of tools will treat the source tree as containing a package, which drives all kinds of behaviors. It is not keyed off of the [build-system] table, and that behavior is specific to uv.
So in the broader ecosystem, any behaviors which you might associate with uv’s handling of no-build-system are probably tied to no-build-system and no-project.
Unless I’ve lost track, the greatest depth of discussion happened in the thread which most-directly preceded this PEP:
(and where, funnily, I was pretty much just an observer and didn’t comment much if at all)
I would say that we are thinking about at least 3 different kinds of projects, probably quite a few more. Collections of scripts are amongst the support targets, but so are…
- packages which are applications
- applications which are not packages (e.g., some non-python-related build process which incorporates python components)
- libraries (i.e., the most “traditional” packages)
- applications which can use a python build process but don’t really care (e.g., webapps which need dependency locking but don’t have any particular need to build a wheel)
I would not try to define the suite of covered scenarios in any prescriptive or narrow way. Any directory containing a pyproject.toml file is covered, if the developer wants to use [dependency-groups] in a spec-compliant manner.