Ugh, the lower bound warnings are super annoying here. I guess I have to make that configurable?

The [build-system] table was created so that projects can be built by any PEP 517 build frontend. This means that you could mix and match tools, allowing people to migrate away from setuptools and for alternative to pip to being built. By reading tool.uv.sources, we support a uv-only feature, something that e.g. python -m build doesn't support. To make it clear that this doesn't build a vendor lock-in, we need to make it clear in the docs:

tool.uv.sources for the build-system table is for development only. It is our equivalent to using pip install -e ./my-setuptools-ext and then building without build isolation: It's our way of feature parity with pip without dropping you out if the uv project interface. We do only support it when building from a directory, we do not support it when building when from an index or a file sdist. Even uv build --wheel --sdist will not recognize it, but give you the default standards-only PEP 517 build experience. As a package author, you need to test that your (published) project does also builds without tool.uv.sources using only published packages.

At some point you may want to support a find-links feature to side load a wheelhouse. You can see an example of how that works in the additional info of #7147. That would impact the lookup at all times and it does work to allow a build backend to find/resolve dependencies that are not distributed externally. As a naive user that’s basically how I think of tool.uv.sources as well.

Separately from that when you say that uv build --wheel won’t use the sources that doesn’t feel like it will be ok in the long term. Build dependencies do not need to be distributed if I’m building a wheel. Only a sdist where building happens by an external system. uv should be able to build my wheel using workspace dependencies and no one else needs them. The wheel can be installed without them.

Even uv build --wheel --sdist will not recognize it

I guess just to poke at this more if we go back to my issue that inspired this work #7147, I'm concerned about @konstin's assertion that uv build --wheel --package my-app wouldn't work with this new feature? Is that true that it wouldn't use the workspace dependency to build the wheel for package my-app which depends on the local workspace package my-setuptools-extension? So I could uv sync properly but not uv build?

Is there anything I can do to help move this forward?

I think uv build would respect this, and you'd need to use uv build --no-sources to avoid it. Are you okay with that, @konstin? I think it would be surprising if uv build didn't run the same build process as our other hooks.

Yeah that's what I'd suggest.

Ok, will rebase and merge this today.