From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH 1/2] gnu: Add numpy Date: Tue, 28 Oct 2014 10:34:48 +0100 Message-ID: <87wq7kh70n.fsf@gnu.org> References: <87bnoyk6g9.fsf@gnu.org> 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]:49797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xj3Ag-0002Az-82 for guix-devel@gnu.org; Tue, 28 Oct 2014 05:34:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xj3Ab-0003cB-5G for guix-devel@gnu.org; Tue, 28 Oct 2014 05:34:34 -0400 Received: from hera.aquilenet.fr ([2a01:474::1]:43080) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xj3Aa-0003c5-NS for guix-devel@gnu.org; Tue, 28 Oct 2014 05:34:29 -0400 In-Reply-To: (Federico Beffa's message of "Mon, 27 Oct 2014 21:26:41 +0100") 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Federico Beffa Cc: Guix-devel Federico Beffa skribis: > On Sun, Oct 26, 2014 at 7:56 PM, Ludovic Court=C3=A8s wrot= e: >> Can these manuals be built from source? > > I get error messages that matplotlib is missing. I started looking at > matplotlib as well, but I've found that, for the TkAgg back-end, it > needs TKinter which is part of the standard python libraries and it is > built if, during the build phase, tk is available. The current python > package does not build that library (no tk). In fact, I would like to > add it to be able to move forward with matplotlib :-) Heh, OK. Then can you just summarize that in a comment with TODO, to give the reader an incentive to look at it? :-) > For the other back-ends some packages are missing (python-gtk, Qt, ...) > > Another annoying problem is that matplotlib needs numpy, thereby > creating a dependency loop (although only for the documentation). If it=E2=80=99s only to build the documentation, we should be able to handl= e it easily (by first building a documentation-less variant of numpy, for instance.) >> If they can but the process is tedious, then it=E2=80=99s OK to leave it= that >> way with a TODO, and also a comment stating what its license is. > > I've not seen any license statement specific for the documentation. > But, given that the source is distributed with the code, can't we just > assume it is the same license? Yes. >>> + (inputs >>> + `(("python" ,python) ; otherwise ld does not find libpython3.3m >> >> This is because Python is not added to =E2=80=98LIBRARY_PATH=E2=80=99, r= ight? >> >> I think this is fixed by this patch: >> >> >> >> Can you confirm? > > Actually it does not. The "...-python-numpy-1.9.0-guile-builder" > still shows that only the python-wrapper is imported. The wrapper does > not include the libraries. Ah right. And what if you again remove Python from =E2=80=98inputs=E2=80= =99, and add #:python ,python to the arguments? That means it will use the actual Python 3.x package, not the wrapper, so everything will be visible. The downside is that there will be no =E2=80=98python=E2=80=99 command, only =E2=80=98python3=E2=80=99. Perhaps the right fix will be to change =E2=80=98python-wrapper=E2=80=99 to= symlink the =E2=80=98lib=E2=80=99 sub-directory of =E2=80=98python=E2=80=99. >> As discussed in the other thread, this should probably be the generic >> (unoptimized) ATLAS here. > > I think that as a temporary situation this is OK. However, in my > opinion it does not make much sense to have a separate sub-optimal > package. I would like to propose to add specific flags to a single > atlas package and, once the new "local-build" flag will be available, > we will remove those flags. Yeah. After some more thought, I=E2=80=99ve finally bit the bullet: 1. Commit 77b0ac9 adds the #:substitutable? flag to gnu-build-system. 2. Commit f15615b uses it for ATLAS. It may still make sense to have the non-optimized version for those who do not need performance and do not want to build locally maybe, WDYT? >> Use the =E2=80=98copy-file=E2=80=99 procedure instead of calling =E2=80= =98cp=E2=80=99. > > The reason that made me use 'cp' instead of 'copy-file' is that the > documentation states that the return value of the latter is not > specified and I'm still not familiar with Guile exception handling. > However, I see many places where 'copy-file' is used without any > 'catch'. In principle this should never fail. If it is OK, I will do > the same. =E2=80=98copy-file=E2=80=99 will throw an exception if something goes wrong= ; since the exception is uncaught, the build process will fail. That=E2=80=99s usually the behavior that we want, so I think it=E2=80=99s b= est. >>> + ;; Tests can only be run after the library has been installed= and not >>> + ;; within the source directory. >>> + (alist-cons-after >>> + 'install 'check >>> + (lambda _ >>> + (with-directory-excursion "/tmp" >>> + (zero? (system* "python" "-c" "import numpy; numpy.test(= )")))) >>> + (alist-delete >>> + 'check >>> + %standard-phases)))))) >> >> Just (alist-replace 'check ...) ? > > Actually the check phase needs to be moved after the install one (see > comment). That's the reason for this two step approach. Ah OK. Thanks! Ludo=E2=80=99.