Improving discoverability of build backends

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.


Packaging :: Build Backend sounds too broad/generic a name for Python-only build backends . Perhaps Python :: Build Backend?

I’m in favour of the idea in general, though.

It would also be nice to extract the Generator from the WHEEL file as metadata.

Ok, looks like a bunch of folks are in favour and no one is opposed. The next steps here would be to:

  1. Add this classifer to PyPI, via a PR on GitHub - pypa/trove-classifiers: Canonical source for classifiers on PyPI. with a back-link/cross-reference to this thread.
  2. Once that’s landed, and released within 24 hours, PyPI will need to be re-deployed with the newer version.
  3. Once active on PyPI (getting listed at, it’s worth commenting here to provide an update.
  4. Ideally, someone will file PRs against a bunch of popular build-backends to add this classifier to them. :slight_smile:

That’s a good feature request against GitHub - pypi/warehouse: The Python Package Index. :slight_smile:

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)?

@fungi: Please see the PS note in the first post, quoted below for visibility.

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.

To bring this discussion back on topic…

That would involve adding Topic :: Software Development :: Python which would be way too generic for the Python Package Index. :wink:

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”).

What about Topic :: Software Development :: Build Tools :: Pyproject Build Backends ?

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 :wink:). My preferred term would be “pyproject.toml-based build backend” but that feels too long. :slight_smile: