[FYI] recently uploaded PyPi packages don't have short package links
See original GitHub issueThe packages used to be under
../../packages/source/<first letter>/<pkg name>/
, now only available as../../packages/<two-char hash>/<two-char hash>/<long hash>/
. The according links also changed in the “simple” index page. This has changed the disk layout of the bandersnatch. Our build system broke due to the mirror of bandersnatch doe not have the same disk layouts in the disk.
Related issues:
- https://sourceforge.net/p/pypi/support-requests/626/
- https://bitbucket.org/pypa/pypi/issues/447/direct-links-of-packages-gone
Example:
There is a package colorlog
with two versions: 2.6.1 (old) and 2.6.3 (new). The following link works fine:
https://pypi.python.org/packages/source/c/colorlog/colorlog-2.6.1.tar.gz
However, if you just change the version number, you will get 404:
https://pypi.python.org/packages/source/c/colorlog/colorlog-2.6.3.tar.gz
The working link to 2.6.3 version is:
Issue Analytics
- State:
- Created 7 years ago
- Comments:10 (10 by maintainers)
Top GitHub Comments
Here is my 2 cents:
I liked the PyPI URLs due to laziness: in 1 copy-and-paste pass I had the source and the md5 info for the recipe. Now that we have to edit the PyPI URL I am tempted to go straight to GitHub.
Of course there are times when we don’t have a choice, like when:
The issue arises when there is a choice. And is more important when the two sources are different. For example: some PyPI source distributions bundle more than just the source. In that case @pelson votes for the hard road to build everything and avoid the bundle. I agree, but I am not against being lazy and postponing that just to get a package in the channel.
So, I think we know now how to do these links. Many examples exist in the feedstocks. Also the example recipe has been updated to use this too. Going to go ahead and close this out.