This is where I keep having trouble with the example here. Speaking as a pip maintainer, we have never suggested or supported the practice of using pyproject.toml to store application dependencies. And there are no standards supporting that usage. As far as I can tell, this is an approach that has originated with uv (other managers like poetry or hatch may support it as well - I don’t have enough experience with them to be sure).
Pip has a strong principle of being based on standards[1], and I’m concerned that if we want to adopt this approach of using pyproject.toml for applications that aren’t meant to be built into a wheel, we should make sure it’s standardised. We’ve had attempts to do that, but not been able to get consensus or a clear way forward.
I’m not against making this an accepted practice. I just want it formalised, so we aren’t making one tool’s implementation defined behaviour something that everyone has to track.
This (recording a set of dependencies that are not intended to go into a wheel) is precisely what dependency groups were intended for. So while the UI might not be ideal for this user, I do think we should be considering whether the problem here is that tools aren’t making the dependency group UI sufficiently usable. Maybe uv should be using dependency group “main” rather than project.dependencies for this case?
Which brings us back to the point that maybe we should get community consensus on how non-wheel projects should be handled.
in reaction to being the “only installer” for so long that “what pip does” became a de facto standard ↩︎
FWIW, when the PEP517/PEP518 builds were implemented in Fedora, we copied pip’s behavior to only fallback to setuptools when there is a setup.py file. That behavior made sense to me, but it was not explicitly stated that way in the PEPs.
If the pyproject.toml file is absent, or the build-backend key is missing, the source tree is not using this specification, and tools should revert to the legacy behaviour of running setup.py (either directly, or by implicitly invoking the setuptools.build_meta:__legacy__ backend).
I think the issue may go deeper. Not sure if it does in this case.
If I was new to the Python ecosystem, I’m pretty sure I wouldn’t understand the difference of “installing” a package and just using it where it is without installing it. Rather, I’d see “it doesn’t work, complains that it cannot find something, so probably I should try installing it”. Then maybe Google for “how to install Python package” if you don’t remember from the past that it’s pip install ..
IOW, I’m not sure the typical user who encounters this wanted to install dependencies. Probably they just saw software that didn’t run and tried what seemed logical to them: Install it.
To be frank, they are not a Python developer and it’s probably how AI did it for them when they asked for a simple FastAPI example.
Yeah, I don’t think it has permeated into the community yet (I will fully admit it didn’t come to my sleep-deprived brain as a solution either). Heck, I don’t think I thought about how that would work without specifying . until I looked at pip install --help to see about specifying the path to pyproject.toml (answer: just point pip at a file path that ends in pyproject.toml and it picks that up as what to read from instead of treating the directory as a path to a source tree).