From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Baines Subject: Re: Prototype for using Guix with python packages Date: Sun, 11 Sep 2016 15:25:29 +0100 Message-ID: References: <4174c012-8e2b-d6f2-8387-031e309b7daf@cbaines.net> <87fupbn713.fsf@gnu.org> <87inu2lfgu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="77HHlIRgL0PmNr3FkbICTb8BlDWTnjqAf" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj5iS-0001zY-AP for guix-devel@gnu.org; Sun, 11 Sep 2016 10:26:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bj5iO-0005yn-36 for guix-devel@gnu.org; Sun, 11 Sep 2016 10:26:39 -0400 In-Reply-To: <87inu2lfgu.fsf@gnu.org> 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: =?UTF-8?Q?Ludovic_Court=c3=a8s?= Cc: guix-devel@gnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --77HHlIRgL0PmNr3FkbICTb8BlDWTnjqAf Content-Type: multipart/mixed; boundary="tE5QoJce93oPqWxJxCmHsF4otKcEcIu9h"; protected-headers="v1" From: Christopher Baines To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= Cc: guix-devel@gnu.org Message-ID: Subject: Re: Prototype for using Guix with python packages References: <4174c012-8e2b-d6f2-8387-031e309b7daf@cbaines.net> <87fupbn713.fsf@gnu.org> <87inu2lfgu.fsf@gnu.org> In-Reply-To: <87inu2lfgu.fsf@gnu.org> --tE5QoJce93oPqWxJxCmHsF4otKcEcIu9h Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/09/16 14:43, Ludovic Court=C3=A8s wrote: >> The main reason why I didn't just improve the importer is that I was >> looking for a way to collaborate around getting multiple versions of >> python packages building and working, and as far as I am aware, Guix >> only contains multiple versions of the same piece of software in some >> special cases? >=20 > That=E2=80=99s right: we keep multiple versions only when people or pac= kages > expect to be able to choose among them (e.g., the various GnuPG series,= > GCC, Python 2.x vs. 3.x). That=E2=80=99s usually a case-by-case decisi= on, > because every additional version that is kept entails additional > maintenance work. >=20 > The same would apply here: we could have multiple versions of some > packages, and only one version of the majority of them. >=20 > What do you think of this approach in the Python context? I've been quite lucky, as I have managed to stay away from using pip and other Python specific packaging things (by using Debian packages), but, lots of people do use these tools. In the future, I would love to be able to use Guix when writing Python, and to encourage others to do similarly. Ignoring myself and generalising, most people who use Python use pip and pip though using pypi.python.org allows installing one of many available versions of a particular package. Therefore, I would think that most people who consider using Guix for a similar use case in which they use pip, would expect to be able to choose among multiple versions of every package. I don't think adding every release of every bit of free software on pypi.python.org in to Guix is feasible, or something that I would want to propose doing, but I still would really like something that gives Guix equal (or greater) utility with respect to Python packages. Which is why I started thinking, and then developing a way of automatically importing releases from pypi.python.org in to a Guix package repository that depends on Guix. All of this is still very uncertain in my mind, in particular, I see Guix as a viable alternative to lots of domain specific package managers, which I would really like to avoid when writing software (e.g. pip, npm gem) but I'm not certain that being a viable alternative to these tools is within the project scope? The other main uncertainty in my mind is whether the approach I have been trying is the best one? I'm getting more confident that this is possible, although there are still technical problems (for example, adding new versions, without breaking existing versions of other packages) that I haven't solved yet. --tE5QoJce93oPqWxJxCmHsF4otKcEcIu9h-- --77HHlIRgL0PmNr3FkbICTb8BlDWTnjqAf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKOBAEBCgB4BQJX1WlhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzRTg5RUVFNzQ1OEU3MjBEOTc1NEUwQjI1 RTI4QTMzQjBCODRGNTc3ERxtYWlsQGNiYWluZXMubmV0AAoJEF4oozsLhPV3PZMQ ALaOAx7HPBnYYtOuIbQR+vAgR9vY4GG1ll+FSktq4F0Boa64GBzl0DBegWYYmdZX aJnJGF3Cmc+DeIcyT+NRJyhTD3Gy33DilDtE1oJPALsE9s5exqE5yPf/ETb+lgF2 N1iqjQmDJ305PWVPj0mHKLsrmfqNIg+bBGLBYBnNBYxwcN71kdth1X8T0hIubsdf lycTJotc5li/mqDVpVIr4OvlkmmKpzpF3YUJz68c5Ub0C5jl5c6RPDZUKfcZ1IfR 8REaou8PyaKlaJVH60Kbjro+R3p+e85w4WZ/cgEXILrGjSzpIe0Zj4yRy1nL17/z uy4FGbT8odKiTgz2wjitEma1JzG6omn1USrxOhgSk64xhHNwvYvdSxP8sc1nc5he WtaPKH8cD4JRmldrv+UofODJebRAtOECg+HOEnu8DqAvumr39jXxIG8+cWRqbEg3 aQsxc4O3BEJHoruohRwzihgWDlBS6BW+/XrQ3umQb+1nPE74nT/0V5AdMf/Ee7Hf KGLWtbmEY2d/AqAhVOIJhUb3TzLab5OondCJnOg4HGY2UlXMWUNRjaLypPrh/MvP cMxT1EBt93mvDTT7eHwaCfY6tkFp/L9HrWraZopOlez9Xi9OIp+aSmkrYmGJepy/ lTtAEm2TwNhRP7KrT5+Ghaus6wtdwhcnUQJ6CnyUax2B =jLSW -----END PGP SIGNATURE----- --77HHlIRgL0PmNr3FkbICTb8BlDWTnjqAf--