proposal of additional badge(s) about cpython/pypi interpreter(s) #43
Description
I like to use your package because it allows to set up the badges locally, for instance moderated by a Makefile (an example). This is helpful for instance if the source code can not (yet) be shared with the public, or access to a third-party platform is restricted (compare e.g., travis-ci/coverall badge on the root repository of PubChemPy on one, and my fork on the other which enjoys using your approach.
It is for these reasons I would like to suggest to extend the present set of badges one may choose from.
Similar to the landing page of python-genbadge on GitHub, it would be nice if one equally could generate the ribbons to document suitable Python / pypi interpreters. So far, I didn't successfully use tox/nox locally, nor within a GitHub action. Yet when uploading a package to pypi.org, does the index "simply" check the package for the corresponding entries in pyproject.toml, or the configuration files specific to tox/nox for the corresponding classifiers like Programming Language :: Python :: 3.13 to then create/relay the badge to GitHub? If so, could this approach be implemented here?
Briefly, I thought the provision of additional badges like about Black; pre-commits, conventional-commits (a bit like seen on the page of commitizen); or about some of the more frequently used licenses listed on Python's list of classifiers as a convenient complement, because
- they might nicely add to "this one space" the package provides
- are more static (compared to e.g., the badge by coverage), and
- (should) find a corresponding entry e.g., in
pyproject.toml, or justified by presence of a.pre-commit-config.yamlfile.
Would one of these proposals fit your envisioned scope of gendbadge?