From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: pypi-uri Date: Wed, 31 May 2017 21:37:16 +0200 Message-ID: <20170531213716.1bfa9a5e@scratchpost.org> References: <02de3feec1033d408e8f9e15cebb9c45@openmailbox.org> <87y3tktva1.fsf@fastmail.com> <1710abf8c15616976d5b79e5e61364ac@openmailbox.org> <8760gntqkm.fsf@fastmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dG9Qu-00049D-CA for guix-devel@gnu.org; Wed, 31 May 2017 15:37:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dG9Qq-0004Wh-9O for guix-devel@gnu.org; Wed, 31 May 2017 15:37:28 -0400 Received: from dd1012.kasserver.com ([85.13.128.8]:45668) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dG9Qq-0004WJ-1e for guix-devel@gnu.org; Wed, 31 May 2017 15:37:24 -0400 In-Reply-To: <8760gntqkm.fsf@fastmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Marius Bakke , guix-devel@gnu.org Cc: =?ISO-8859-1?Q?Jos=E9?= Miguel =?ISO-8859-1?Q?S=E1nchez_Garc=EDa?= 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: vs . 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 (note: case is wrong, should be "uWSGI") and it works (!). So I guess we can remove the special case again.