best-of-python-dev: a ranked, auto-scored index of 270 Python developer tools

What best-of-python-dev is, and who the shortlist is for

The README describes the repository as a curated list of 270 open-source projects, grouped into 17 categories, all ranked by a project-quality score calculated from metrics collected from GitHub and different package managers. The categories run from Linters & Style Checkers (41 projects) through Testing Tools (43 projects) and Documentation (28 projects) down to Shell (2 projects) and a single-entry Others bucket. That shape tells you who it is for. If you are choosing a linter, a formatter, a test runner or a docs generator and you do not yet have a candidate, the list narrows the field before you spend an afternoon reading READMEs. It is less useful if you already know you want ruff and need to know which config keys changed in the last release. The README does not claim to benchmark anything, and the ordering is not a statement about code quality, only about the collected metrics. Treat it as a starting map with coordinates, not as a verdict.

How the ranking is generated and what the symbols mean

The list is not hand-ordered. According to the README, projects are ranked by a project-quality score computed from metrics automatically collected from GitHub and package managers, and the whole list is regenerated weekly. Each entry carries an explanation key: medals for the combined project-quality score, a star count from GitHub, a chick for projects less than six months old, a sleeping symbol for inactive projects (six months without activity), a skull for dead projects (twelve months without activity), arrows for trending up or down, a plus for recently added entries, and a warning sign for issues such as a missing or risky licence. Counts of contributors, forks, issues, package-manager timestamps, downloads and dependent projects are also shown per entry. Two design decisions are worth naming. First, the freshness signals are computed from activity, so a mature tool that simply stopped shipping releases will be flagged as inactive even if it is finished rather than abandoned. Second, the warning flag is coarse: pylint carries a GPL-2.0 marker in the same visual language as a missing licence, which is a different problem entirely. Read the flag as "look at this", not as "avoid this".

Reading an entry: the ruff and pylint cards side by side

Each project sits inside a collapsible block with a one-line description, a licence code, and install snippets for the sources the generators found. The ruff entry, for example, carries an MIT code and three install paths: a git clone, a pip install and a conda install. The pylint entry carries GPL-2.0 and a downward trending arrow. Having the clone, pip and conda lines in the same block is the practical value here: you can see at a glance whether a tool is distributed on conda-forge as well as PyPI, which matters if your environment is conda-managed. The snippets are copied from the sources the generator reads, so they reflect the package names as published rather than a rewritten instruction set. What the cards do not give you is a usage example, a config file, or a note about which Python versions are supported. For that you follow the link to the project's own repository, which is where the list expects you to end up.

Installing nothing: cloning the list and pulling a first candidate

There is no package to install. best-of-python-dev is a repository you read, and the README points contributors at projects.yaml for edits. The practical first step is to clone it and read the data file locally, which is faster than scrolling the rendered README when you want to filter by category.

git clone https://github.com/ml-tooling/best-of-python-dev

After the clone you have projects.yaml at the repository root alongside README.md, CONTRIBUTING.md, LICENSE and the config/ and history/ directories. The YAML file is the source the README is generated from, so it is the place to look when you want to check whether a project is still listed. From there, take a candidate's install line straight from its card. The ruff card gives these three, and the README shows them exactly as below:

pip install ruff
conda install -c conda-forge ruff
git clone https://github.com/charliermarsh/ruff

What you should see after pip install ruff is the ruff executable on your path; the list does not document a first-run command, so the next step is the project's own documentation. The same pattern applies to pylint, flake8 and everything else in the catalogue: the list hands you the package name and the distribution channels, and the linked repository takes over from there.

Where the catalogue stops being useful

The score is a ranking signal, not a compatibility check. Nothing in the README says the generator resolves dependency conflicts between the projects it lists, so picking a linter, a formatter and a type checker from three different cards can still produce overlapping rules or conflicting config files. The staleness flags are another soft edge: a project marked inactive may be complete, and a project marked new has no track record, yet both appear in the same ranked list with scores that are computed the same way. The licence handling is the sharpest limitation. The list flags a risky or missing licence with a warning icon and prints a licence code per entry, but the README does not describe how the generator determines that code or how it treats dual licensing. If you are assembling a dependency set for a commercial product, the card is a pointer to the licence file, not a substitute for reading it. Finally, the catalogue is Python-specific and developer-tooling-specific. If your question is about runtime libraries, web frameworks or data tooling, this is the wrong list.

How it differs from a package index or an awesome list

The obvious comparison is PyPI search or a plain awesome-list. PyPI tells you a package exists and lets you install it; it does not rank, and it does not group by role. A hand-maintained awesome list groups by role but leaves the ordering to the author's taste and tends to rot as links go stale. best-of-python-dev sits between the two: it groups by role like an awesome list, but the ordering and the freshness flags are regenerated weekly from collected metrics, and the release history shows dated updates such as 2026.08.27, 2026.08.20 and 2026.08.13. That cadence is the actual differentiator. The trade-off is that an automated score cannot tell you that a tool is pleasant to use. A human curator can say "this one has the better error messages"; the score can only count what GitHub and the package managers expose. If you want opinionated prose about ergonomics, a maintained awesome list written by a practitioner will beat this. If you want a ranked, dated snapshot you can re-derive, this wins.

Maintenance, licence and the cost of following the list

The repository is not archived, and the last push was on 2026-09-10, so the weekly regeneration described in the README is current. The release history shows dated update releases rather than semantic versions, which means there is no upgrade path to manage: you either pull the latest state or you do not. Your ongoing cost is the cost of re-reading, not the cost of migrating. The list itself is licensed CC-BY-SA-4.0, which is a content licence rather than a software licence, and it applies to the catalogue, not to the projects inside it. Each project carries its own licence code in its card, and the README marks some of them with a warning icon. The README does not explain the criteria behind those warnings, so the reasonable reading is that the flag exists to make you open the project's licence file. That is a documentation gap, and it is the one I would want closed first, because a warning icon with no stated rule is easy to ignore and easy to over-trust.

Editorial conclusion

Adopt best-of-python-dev if you need a shortlist before you start comparing linters, formatters, test runners or documentation generators, and if you are willing to check each candidate's own repository before committing. Do not adopt it if you need a dependency resolver, a version pinner or a curated security review: the README states the ranking is computed from metrics collected from GitHub and package managers, and it carries warning icons such as the GPL-2.0 tag on pylint, but it does not audit licences for you. Before you rely on a category, open projects.yaml, confirm the entry you care about is still listed, and read the linked repository's own install instructions rather than the snippet in the list.

Frequently asked questions

Official sources

1. License: CC-BY-SA-4.0
2. ml-tooling/best-of-python-dev on GitHub
3. Project website
4. README
5. Releases