Hi, >> Can you change this to use 'pypi-uri' instead? > Any reason why `guix import` doesn't do that by default? I just copied > the output from that command, so I believed it was the way it should > be done.
PyPI switched to content-addressing only (with a hash function different from ours) and doesn't support fetching a package by name with the usual simple URL anymore. Therefore, we are using pypi.io as an alternative. Example: <https://pypi.python.org/packages/fa/12/4a837dc26173819a29e713cbfb490a83d5296545abbe53422d7b14604d8f/marshmallow-3.0.0b2.tar.gz> vs <https://pypi.io/packages/source/m/marshmallow/marshmallow-3.0.0b2.tar.gz>. Unrelated to this, back in the day I adapted make-pypi-sexp to handle a special case (for example for uwsgi): pypi urls are case-sensitive and for some reason in Guix we mangle the package names to be all-lowercase. That means that (naturally) some of the urls returned by pypi-uri don't work because the case is different. So I've adapted make-pypi-sexp to find out whether the pypi-uri and the actual source url it just downloaded from agree - and if not, it prefers the latter. The latter just worked when downloading it so it's the safe choice. That said, I've just tried to fetch <https://pypi.io/packages/source/u/uwsgi/uwsgi-2.0.15.tar.gz> (note: case is wrong, should be "uWSGI") and it works (!). So I guess we can remove the special case again.
