Short version, although you already got an answer:
If everyone had to use it, and everyone were only allowed to use "static" dependencies determined ahead of time, yes. But:
* legacy projects that don't use pyproject.toml are still supported
* it's possible to publish an "sdist" source package that's built on the user's machine (for example, because it includes C code that's highly machine specific and needs to be custom built for some reason; or because the user wants to build it locally in order to link against large, locally available libraries instead of using a massive wheel that copies them)
* When something is built locally, it's permissible to determine the dependencies during that build process (and in some rare cases, that may be another reason why an sdist gets used - the user's environment needs to be inspected in order to figure out what dependencies to fetch)
* Even if it did work, `pyproject.toml` is really more like "source code" for the metadata (about dependencies and other things). The real metadata is a file called `PKG-INFO` when it appears in an sdist, or `METADATA` in a wheel. The format is based on email headers (yes, really).
In short, you can get metadata from pyproject.toml, but (a) it can still involve executing code due to PEP 517 hooks, and (b) a malicious package would use the legacy setup.py to get their code executed.
That's a super helpful diagram. Saved it for later in case I have to explain to someone else. Thank you. I can see why something like pipask would be helpful. I saw in another comment that you are looking to make a uv plugin. I'll be on the lookout for that getting released!
If everyone had to use it, and everyone were only allowed to use "static" dependencies determined ahead of time, yes. But:
* legacy projects that don't use pyproject.toml are still supported
* it's possible to publish an "sdist" source package that's built on the user's machine (for example, because it includes C code that's highly machine specific and needs to be custom built for some reason; or because the user wants to build it locally in order to link against large, locally available libraries instead of using a massive wheel that copies them)
* When something is built locally, it's permissible to determine the dependencies during that build process (and in some rare cases, that may be another reason why an sdist gets used - the user's environment needs to be inspected in order to figure out what dependencies to fetch)
* Even if it did work, `pyproject.toml` is really more like "source code" for the metadata (about dependencies and other things). The real metadata is a file called `PKG-INFO` when it appears in an sdist, or `METADATA` in a wheel. The format is based on email headers (yes, really).