[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
pypi-uri
From: |
Danny Milosavljevic |
Subject: |
pypi-uri |
Date: |
Wed, 31 May 2017 21:37:16 +0200 |
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.
- pypi-uri,
Danny Milosavljevic <=