I reckon it’d be a good idea to add a classifiers to PyPI, for Python packaging build backends?
Topic :: Software Development :: Packaging
Topic :: Software Development :: Packaging :: Build Backend
Do we think adding these two, so that we can have a single place to point to, and say “hey, there’s the known build backends” is worthwhile? This would enable users to search through the list of tools available.
There’s a Topic :: Software Development :: Build Tools already but that’s exceedingly generic – it applies to CMake, which is not the same as scikit-build (which is meant to be(come?) a build-backend that gets specified in pyproject.toml).
PS: Please don’t bike-shed what additional names under Packaging we could add – I really don’t want to derail this discussion into “what else makes sense”. This is a specific proposal that has value on its own and we have the ability to extend this later.
Not all build backends are also build frontends (or vice versa). Should there not be classifiers for each (and then projects which implement a backend and a frontend can declare both if they like)?
Sorry, I was confused by the relationship of the proposed classifier
to the wheel generator metadata discussion, since I have a build
backend which would make use of this classifier but its reliance on
the wheel library’s writer means that the two are not synonymous.
The distinction I meant to make is that not all build backends
implement their own wheel writer, but I misunderstood PEP 517’s
terminology section as implying that wheel writers are implicitly
build frontends.
In the meantime, a separate issue has been opened against wheel to
request that it allow callers to alter the content of that field,
which addresses my concerns over conflating wheel generator and
build backend names.
That would involve adding Topic :: Software Development :: Python which would be way too generic for the Python Package Index.
And… to pre-empt the next obvious question: Topic :: Software Development :: Python Packaging would be too specific (especially given that other software development topics are things like “Web Development”).
I am not fond of calling anything “pyproject” on its own, since the entire filename is required to be unambigous about what we’re referring to (eg: in case we define a pyproject.lock format in the future ). My preferred term would be “pyproject.toml-based build backend” but that feels too long.
We’re getting a little off topic here (and I can thread split if needed), but it would only be ambiguous if a similar “thing” exists (or might conceivably exist) in both files, and the distinction is meaningful in the relevant context—there is not, I presume, going to be a whole independent class of “pyproject.lock-based build backends” separate from the “pyproject.toml-based build backends” (at least, I hope not ).
Also, at least as I understand it, “pyproject build backend” is a discrete term intended to replace “PEP 517 build backend”—i.e., a backend providing the pyproject hooks originally defined in PEP 517 (etc.) and called by the pyproject-hooks reference implementation. The “pyproject” refers to the hooks (which are fundamentally what the backend needs to support in order to be considered a “pyproject build backend”) rather than the pyproject.toml file specifically (which IIRC a conformant backend isn’t strictly required to interact with at all, aside from including/excluding the file when copying files to sdists/wheels).
Taking this argument a little further, I like @henryiii’s suggestion of “Python build backend”. It’s not like we’re going to have any other sort of “Python build backend” in the foreseeable future.
I don’t have a real problem with @henryiii 's proposed PyPI classifier if that’s what people agree on to unblock this; in that context it could be an advantage that it covers Python packaging build tooling more broadly as opposed to just just backends that support pyproject hooks specifically, and at least for near-future versions of PyPI-distributed projects that adopt the tag, they are very likely (though not certain) to be the latter anyway.
In the wider context, not sure if you’re actually proposing such, but FTR I don’t think its a good idea to use “Python build backend” as a replacement for the existing specific “Pyproject build backend” term generally (that already recently replaced “PEP 517 build backend” and similar), as:
It doesn’t serve the same purpose as the more precise term, as unlike the former, the latter specifically denoting backends implementing the Pyproject hooks interface originally defined by PEP 517, as opposed to, e.g.:
distutils
older but still-widely-used versions of many tools that don’t support PEP 517/pryproject hooks (Setuptools, buildout, Scikit-Build, Enscons, etc)
other Python-related build tools that don’t support pyproject builds (e.g. Pex, Spack, Conda, etc.)
Any future or alternative standard for backends
It would be inconsistent and potentially confusing with the existing “pyproject xxx” names now used for, e.g. pyproject builds, pyproject metadata, pyproject hooks, etc., as well as the existing pyproject build backend/frontend nomenclature, etc.
It could also be potentially confused with build tooling for Python itself, particularly in certain contexts
).