Security News
Maven Central Adds Sigstore Signature Validation
Maven Central now validates Sigstore signatures, making it easier for developers to verify the provenance of Java packages.
Pyroma rhymes with aroma, and is a product aimed at giving a rating of how well a Python project complies with the best practices of the Python packaging ecosystem, primarily PyPI, pip, Distribute etc, as well as a list of issues that could be improved.
The aim of this is both to help people make a project that is nice and usable, but also to improve the quality of Python third-party software, making it easier and more enjoyable to use the vast array of available modules for Python.
It's written so that there are a library with methods to call from Python, as well as a script, also called pyroma.
It can be run on a project directory before making a release:
$ pyroma .
On a distribution before uploading it to the CheeseShop:
$ pyroma pyroma-1.0.tar.gz
Or you can give it a package name on CheeseShop:
$ pyroma pyroma
Giving it a name on CheeseShop is the most extensive test, as it will test for several things isn't otherwise tested.
In all cases the output is similar::
------------------------------
Checking .
Found pyroma
------------------------------
The packages long_description is quite short.
------------------------------
Final rating: 9/10
Cottage Cheese
------------------------------
This is the list of checks that are currently performed:
The package should have a name, a version and a Description. If it does not, it will receive a rating of 0.
The version number should be a string. A floating point number will work with distutils, but most other tools will fail.
The version number should comply to PEP386.
The description should be over 10 characters, and the long_description should be over a 100 characters.
Pyroma will convert your long_description to HTML using Docutils, to verify that it is possible. This guarantees pretty formatting of your description on PyPI. As long as Docutils can convert it, this passes, even if there are warnings or error in the conversion. These warnings and errors are printed to stdout so you will see them.
NB! Currently this doesn't change the rating, this is because Docutils no longer raises an error during this process, so I have to rewrite the test. Once it's reinstated, incorrect syntax will be fatal.
You should have the following meta data fields filled in: classifiers, keywords, author, author_email, url and license.
You should have classifiers specifying the supported Python versions.
You should have requires-python
/python_requires
specifying the Python versions you support.
You should have a classifier specifying the project license.
If you are checking on a PyPI package, and not a local directory or local package, pyroma will check the number of owners the package has on PyPI. It should be three or more, to minimize the "Bus factor", the risk of the index owners suddenly going off-line for whatever reason.
If you are checking on a PyPI package, and not a local directory or local package, pyroma will check that you have uploaded a source distribution, and not just binary distributions.
With pre-commit <https://pre-commit.com>
_, pyroma can be run whenever you
commit your work by adding the following to your .pre-commit-config.yaml
:
.. code-block:: yaml
repos:
- repo: https://github.com/regebro/pyroma
rev: "3.2"
hooks:
- id: pyroma
The project was created by Lennart Regebro, regebro@gmail.com
The name "Pyroma" was coined by Wichert Akkerman, wichert@wiggy.net
Contributors:
Fall back to installing project's build backend in an isolated environment if a compatible version isn't installed in the current env [CAM-Gerlach]
Fix metadata extraction failure when project long_description
is included
as a header rather than a payload in the METADTA
file [CAM-Gerlach]
Add a fallback to restore compatibility with Setuptools <61 [CAM-Gerlach]
Fix tests failing due to invalid versions on Setuptools >=66 [CAM-Gerlach]
Add python_requires
, update classifiers, add implicit dependencies
and remove unused deps in Pyroma's own packaging metadata [CAM-Gerlach]
Moved from a custom trove classifiers list to using the trove-classifiers package [hugovk]
Support checking the Requires-Python metadata [davidandreoletti]
Silence noisy build backend output when building metadata [CAM-Gerlach, wesleybl]
Official support for Python 3.11 [hugovk, radarhere]
Some string formatting bugs [hugovk, CAM-Gerlach]
Now follows black and flake8 rules
Check if author_email field contains author name [bessman]
The deprecation test for test_suite is no longer needed, as the patched setuptools method of gathering metadata as a whole is deprecated.
description_content_type
also needs a mapping in the metadata map.
build
to build the metadata as a
preferred build method over the old patched setuptools method.
The old way is depracated and will be removed in 5.0, which also is
planned to support PEP621.
Thanks to Christopher A.M. Gerlach for valuable insight into the
modern packaging systems.test_suite
Added support for pre-commit [CAM Gerlach]
Rewrote parts of the PyPI support, to avoid using the xmlrpc API, since it's being heavily rate-limited at the moment. Only one call is using it now, which seems to work fine.
Backwards incompatible change: As a result of the above change, when looking for packages on PyPI, the package name must now be spelled exactly correct, including capitalization.
Some more code cleanup/modernization [CAM Gerlach]
Added --quiet option to output only the rating [Hugo van Kemenade]
Pyroma is now an executable module, and can be called with python -m pyroma
[RuRo]
Added correct detection of setup.py encoding
Code cleanup [CAM Gerlach]
Drop support for Python 2 [Florian Bruhin]
Add back official support for Python 3.6, I didn't realize it was still officially supported
Update to the current list of Trove classifiers.
Officially support Python 3.8 and 3.9
Drop official support for Python 3.5 and 3.6 (still works though).
Ran flake8 and black on the code, better formatting for classifiers.py generation.
Support for PEP 517, setup.cfg-only packages. [Max Tyulin]
Adds support for Markdown long_descriptions, if you set long_description_content_type to 'text/markdown'
Installs Pygments to avoid an error message of you have syntax highlighted code in the long_description.
Fixed #35: Correctly restore sys.argv
. [maurits]
Added back the BusFactor test, the XMLRPC API supports it.
#26: Adding a test to check for a development status classifier.
#21: Accept the new project_urls distribution data.
Now verifies that classifiers are valid, and that the license field and license classifiers match.
The rating now again reflects if the long_description isn't valid ReST.
#38: Recommendations for the License field has changed.
Get rid of the tests that rely on HTML scraping, it's too brittle.
Update to use pypi.org instead of pypi.python.org [Andreas Lutro, Lennart Regebro]
Added -n command line option to set the minimum rating needed for pyroma to return success, useful in scripts. [Scott Colby]
Check that a classifier specifies the project license. [4383]
Dropped support for Python 2.6, 3.3 and 3.4.
Fixed a unicode issue [gotcha]
Stopped recommending places to keep documentation.
Removed the TestSuite rating. I decided it was too close to looking at code quality. Pyroma no longer cares if you have tests or not.
Fixed #36: PyPI now requires https.
Made it run under Python 3 again.
PEP8
More robust rating. [Jeff Quast]
Closed #24.
Package name lookup is now case insensitive. [Dmitry Vakhrushev]
Fixed yet another error in return value. [Dmitry Vakhrushev]
Fixed issue #17: Integration with zest.releaser stopped working.
Fixed issue #18: Pyroma returns the rating as an exit code, this was a mistake. It now returns 0 on success, 1 on incorrect options and 2 if the rating is below 8.
Fixed issue #19: Implementing a custom test class counts as having tests.
8: Philadelphia is now considered a "success" based on practical experience.
Fixed issue #13: Pyroma would fail if there was no description.
Dropping support for Python 3.1. It still works, but it is unsupported.
Added support for command line options, implementing #14 and #15.
Issue #13: Pyroma would fail when checking a package name if no source distribution could be found.
Added a check that the package has a source distribution on PyPI.
Issue #11: pyroma would fail if long_description was a non-string.
zest.releaser now only runs Pyroma on Python packages.
Because packages that use external test-runners can not get more that 9/10, this value is now also seen as acceptable when running Pyroma through zest.releaser.
Added a test to make sure the version number is a string.
Made sure errors were printed also when a fatal error was encountered.
Better log messages.
The zest.releaser hook is now done before tagging, as it's more useful there. Especially in conjunction with check-manifest.
Having no long_description no longer causes pyroma to fail.
Removed the running of tests. I always found it a bit iffy, and getting rid of it solved a lot of issues. Pyroma is now focused solely on packaging quality.
A package on PyPI with several versions will no longer return an error.
Now looks for documentation on pythonhosted.org or readthedocs.org.
Adds a hook for zest.releaser, so it can be run after doing the checkout, before uploading to PyPI.
Better handling if there is no package data, for example if setup.py doesn't call setup() unless you run it as the "main" script.
If setup.py doesn't call setup() look for a main() script and try to run it.
Support for Python 3.3
Added test for PEP 386 compliance.
It's now using a ProxyStub for the PyPI xmlrpclib during tests.
Removed the Dependency rating.
Added a rating that runs tests, to see if they run. This will also take care of checking for dependencies.
Commented out the dependency test, it was too unreliable.
Fixed the ReST.
Python 3 support.
FAQs
Test your project's packaging friendliness
We found that pyroma demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Maven Central now validates Sigstore signatures, making it easier for developers to verify the provenance of Java packages.
Security News
CISOs are racing to adopt AI for cybersecurity, but hurdles in budgets and governance may leave some falling behind in the fight against cyber threats.
Research
Security News
Socket researchers uncovered a backdoored typosquat of BoltDB in the Go ecosystem, exploiting Go Module Proxy caching to persist undetected for years.