aiomysql: PyPi releases do not always match repo code
While trying to work out why installing 0.0.17
still triggered the issue outlined in #302, I started looking at other versions and discovered that a few of them don’t appear to match the code tagged for that release in this repo.
I’ve done a rudimentary check on the last 5 versions by doing a very lazy test, just checking if the version of pymysql
matches between the git tag and the pypi release, here are the results:
0.0.15
: match
$ docker container run -it --rm python pip install aiomysql==0.0.15 | grep -F 'Collecting PyMySQL'
Collecting PyMySQL>=0.7.5 (from aiomysql==0.0.15)
0.0.16
: doesn’t match
$ docker container run -it --rm python pip install aiomysql==0.0.16 | grep -F 'Collecting PyMySQL'
Collecting PyMySQL<0.9,>=0.7.5 (from aiomysql==0.0.16)
0.0.17
: doesn’t match
$ docker container run -it --rm python pip install aiomysql==0.0.17 | grep -F 'Collecting PyMySQL'
Collecting PyMySQL<=0.9.2,>=0.9 (from aiomysql==0.0.17)
0.0.18
: no release
$ docker container run -it --rm python pip install aiomysql==0.0.18 | grep -F 'Collecting PyMySQL'
err: No matching distribution found for aiomysql==0.0.18
0.0.19
: match
$ docker container run -it --rm python pip install aiomysql==0.0.19 | grep -F 'Collecting PyMySQL'
Collecting PyMySQL<=0.9.2,>=0.9 (from aiomysql==0.0.19)
At best this is awfully confusing because according to the code 0.0.17
was the first release to have the conservative version pinning for pymysql
, but in fact that’s some how made it into the 0.0.16
release (which the code doesn’t reflect) but not into 0.0.17
.
It’s a little unsettling to find that the versions released in PyPi don’t always match the tagged code releases. Is this some sort of mistake or quirk in the shipping process? 😕
Possibly related: https://github.com/aio-libs/aiomysql/issues/318
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 36 (30 by maintainers)
I am on long business trip, do not have lots of time right now. Will take a look once back to the town.
Which proves to be error-prone because of human presence in deployment chain.
@terrycain you cannot edit published dists.