From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: proper Python inputs (was: gnu: Add python-pytest-pep8.) Date: Tue, 26 Apr 2016 16:19:16 +0200 Message-ID: References: <1461244921-7412-1-git-send-email-donttrustben@gmail.com> <1461503184-8841-1-git-send-email-donttrustben@gmail.com> <1461503184-8841-4-git-send-email-donttrustben@gmail.com> <20160424170405.GA12480@debian-netbook> <571D5AA1.9090605@gmail.com> <571E0F66.2070703@gmail.com> <20160425181903.GE8957@jasmine> <571E791C.40802@crazy-compilers.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1av3po-0000tO-1Y for guix-devel@gnu.org; Tue, 26 Apr 2016 10:19:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1av3pj-0002uu-Up for guix-devel@gnu.org; Tue, 26 Apr 2016 10:19:27 -0400 Received: from venus.bbbm.mdc-berlin.de ([141.80.25.30]:48548) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1av3pj-0002ul-K4 for guix-devel@gnu.org; Tue, 26 Apr 2016 10:19:23 -0400 In-Reply-To: <571E791C.40802@crazy-compilers.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: Hartmut Goebel Cc: guix-devel@gnu.org Hartmut Goebel writes: > Am 25.04.2016 um 20:19 schrieb Leo Famulari: >> This seems like an unusual case, since the package in question appears >> to be a build-time tool. So, it would make sense to have things like >> python-pytest available during python-pytest-pep8's run-time. > >> If we have a use case for python-pytest-pep8, it could be worthwhile >> to see if it will work without propagating these anyways; I've noticed >> some Python packages have a way to link to non-propagated-inputs.=20 > > Reading this makes me *totally* confused about how to package Python fo= r > Guix. I think, we should enhance the Guix Python Packaging guide to > clarify thinks for all. > > 1. Fact: If some Python package lists another package in > "install_requires", then this other Python package is required to run. > In a non Guix-environment, pip would install these other package, too. > > 2. Until 5 minutes ago I thought, that adding these other packages as > "normal" inputs is enough. But then I found that quite a bunch of > packages are using "propagated-inputs". So I tried to find out, what th= e > difference is: > > - "normal" inputs get added to PYTHONPATH via the .pth mechanism. > > Example: guix package -i python-execnet puts only > "execnet-1.4.1-py3.4.egg" into site-packages, plus > "python-execnet-1.4.1.pth", which adds the required package via a link > to "/gnu/store/....python-apipkg-1.4/..." > > - "Propagated" inputs are all linked into site-packages > > Example: guix package -i python-zope-interface puts zope-interface > and zope-event into site-packages. > > So this is not much of a difference: In both cases all required inputs > will be available in PYTHONPATH at run-time and can be imported. > > 3. But anyhow: Trouble is ahead: If some package aaa has a normal input > "zzz@1.2", while package bbb as normal input "zzz@1.1" and package ccc > as propagated input "zzz@1.3", we will end up with this in site-package= s: > > - aaa.pth adding path to zzz@1.2 > - bbb.pth adding path to zzz@1.1 > - zzz-1.3.egg > > Which package "zzz" gets imported is somewhat arbitrary [2]. > > Is this intended? Did I miss something? It=E2=80=99s not so easy as =E2=80=9Cpth=E2=80=9D files aren=E2=80=99t ne= cessarily evaluated. Usually we propagate inputs that need to be available at runtime. This often causes problems here at work when people installed =E2=80=9Cpython2-numpy=E2=80=9D a couple of months ago and then install =E2= =80=9Cmiso=E2=80=9D which propagates =E2=80=9Cpython2-numpy=E2=80=9D. There are then at least two = variants of numpy in the profile leading to many collisions. We=E2=80=99ve previously discussed alternatives to propagation: http://lists.gnu.org/archive/html/guix-devel/2016-02/msg00810.html But so far there haven=E2=80=99t been any patch-ready solutions. I=E2=80= =99d really like to fix this, though, as it=E2=80=99s uncomfortable to have to tell u= sers to either use manifests (thereby upgrading all of their applications in their profile before installing something new) or to use separate profiles for Python stuff. ~~ Ricardo