In theory, I would say yes.
In practice, “assume they are present, if any” is the only practical way for an installer to respond.
But this would (if I’m thinking and reading straight) also make my proposed enhancements non-conforming, unless the prompting options claimed that legacy projects definitely don’t have any missing external build dependencies. Which seems misleading, and counter to the intended purpose of prompting the user.
So I lean in favour of what you’re saying.
The blithe answer is that anyone putting out an sdist for a pure Python package should be getting pressured to publish wheels anyway.
But then, the same problem could also apply to a project that needs to be built, but where the build system is expected to bundle all the needed build-time dependencies. (Although the examples I can think of for this sound… rather strained.)
A package that wants to advertise that there are no external build dependencies, can explicitly put empty lists for those keys in [external]
. Or at least put an empty [external]
table in the pyproject.toml
. I don’t think that a separate mechanism is required to communicate this. “Explicit is better than implicit”, but “special cases aren’t special enough to break the rules”.
A project that assumes a dependency is present, and explicitly declares not having that dependency on the strength of that assumption, is doing so at its own risk - and it should be considered a bug in the project’s packaging.
I don’t think the “pure-Python package” distinction is particularly useful to the install process. Such projects are only a subset of those which “cause no problems”. (I’m not even sure it’s well defined. May a “pure-Python” have runtime dependencies that themselves use C extensions, for example?)
In general, if we’re going to have backwards-compatibility mechanisms surrounding pyproject.toml
tables, then “the table is completely missing” really needs to mean “this project predates the standardization of the table, or hasn’t been updated to that standard” - and thus the values that such a table would have are necessarily unknown.
By my understanding of the PEP, PURLs only get used in lists (TOML arrays), so the natural value to signal this is an empty list.