guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] gnu: Add numpy


From: Federico Beffa
Subject: Re: [PATCH 1/2] gnu: Add numpy
Date: Mon, 27 Oct 2014 21:26:41 +0100

On Sun, Oct 26, 2014 at 7:56 PM, Ludovic Courtès <address@hidden> wrote:
> 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 :-)

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 they can but the process is tedious, then it’s 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?

>> +    (inputs
>> +     `(("python" ,python) ; otherwise ld does not find libpython3.3m
>
> This is because Python is not added to ‘LIBRARY_PATH’, right?
>
> 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.

> 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.

>
>> +       (alist-replace
>> +        'build
>> +        (lambda* (#:key outputs inputs
>> +                  #:allow-other-keys #:rest args)
>> +          (let* ((build (assoc-ref %standard-phases 'build))
>
> Use ‘alist-cons-before’ instead of calling the original ‘build’ phase (I
> think this was discussed before and there was rough consensus on that.)

OK.

> Just use (string-append ,name "-" ,version) so the ‘package-name’
> procedure isn’t needed.

that's much better :-)

> Use the ‘copy-file’ procedure instead of calling ‘cp’.

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.

>
>> +         ;; 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.

Thanks for the comments.
Regards,
Fede



reply via email to

[Prev in Thread] Current Thread [Next in Thread]