In psf/requests, the tag v2.16.1 points at code whose __version__.py says 2.16.0. The tag v2.16.0 says the same, and the code differs between them.
Check it in 30 seconds, nothing to install:
curl -sO https://raw.githubusercontent.com/luizfnsilva/closure_drift/v1.1.0/closure_drift.py
git clone -q https://github.com/psf/requests && cd requests
python3 ../closure_drift.py --compare v2.16.0 v2.16.1
DIFFERS UNDER ONE LABEL: both declare 2.16.0, and the code differs
in 2 path(s). If both were published, that label names two things.
Or without the tool, with plain git:
git show v2.16.1:requests/__version__.py | grep __version__
# __version__ = '2.16.0'
The two paths are a fix to how urllib3's version is parsed and a restored module. The tag was cut before the version was bumped. That is common, not a verdict on requests: among the 100 most-downloaded PyPI projects with a public repository, 29 have at least one version label that names two code states.
What a tag does not tell you
A tag is not a release. The tool reads git, so it cannot see which commit a package on PyPI was built from. Two people outside the project showed me where that matters. In ruff, v0.0.268 was tagged and never published. In openai-python, the 0.26.5 on PyPI was built from the commit after the tag.
closure_drift 1.1.0 lets you say which versions were released. Give it a file with one version per line, from your release notes or your registry:
closure-drift --published released.txt
Only tags on the list are compared. A tag left off is left out of the analysis. The tool never calls it unpublished, because it still reads only git.
Then run it in your own repository:
python3 closure_drift.py
One file, no dependencies, read-only. Source and method: https://github.com/luizfnsilva/closure_drift (DOI 10.5281/zenodo.23271569).
Written with AI assistance; every command and number above was run and checked.
Top comments (0)