On Tue, Oct 28, 2014 at 10:34 AM, Ludovic Courtès <l...@gnu.org> 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
