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: Tue, 28 Oct 2014 18:49:07 +0100

On Tue, Oct 28, 2014 at 10:34 AM, Ludovic Courtès <address@hidden> wrote:
> Ah right.  And what if you again remove Python from ‘inputs’, 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
> ‘python’ command, only ‘python3’.

Well, as you say, it does not find the 'python' command and stops with
an error.  I think that fixing the command name is even worse that
having python as input.

>
> Perhaps the right fix will be to change ‘python-wrapper’ to symlink the
> ‘lib’ sub-directory of ‘python’.

It was also suggested to make python a propagating input of the wrapper.
https://lists.gnu.org/archive/html/guix-devel/2014-10/msg00303.html

In my opinion, one of these two fixes would be desirable.

> After some more thought, I’ve finally bit the bullet:
>
>   1. Commit 77b0ac9 adds the #:substitutable? flag to gnu-build-system.
>
>   2. Commit f15615b uses it for ATLAS.

Wow! That was quick. Thanks!

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

Personally my main use of ATLAS is through numpy/scipy. Therefore I
would like to be able to use a good performing ATLAS with those
packages.  If that needs a manual installation step, that's fine with
me.

In principle we could make a second package and add a suffix to the
version number such that the general binary version takes precedence.
To get a locally built library one would then have to give an explicit
ATLAS version to guix.  Or, do you have other approaches in mind?

Regards,
Fede



reply via email to

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