Re: Guix on clusters and in HPC

[ludo@gnu.org (Ludovic Courtès)]

Hi!

Ben Woodcroft <b.woodcroft@uq.edu.au> skribis:

> I'm a little late here, but please do all of the things on that list :)

:-)

> With this suggestion:
>
>     + for [[https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00005.html][CPU-specific optimizations]]
>     + somehow support -mtune=native (and even profile-guided
>       optimizations?)
>
> I'm not sure if you already thought of this, but an important use case is that of pipelines, where we may want to optimise not just the package being built, but instead one (or more) of its dependencies. So your suggestion of this syntax:
>
>   guix package --tune=haswell -i diamond
>
> requires some extensions, maybe something like this, where bamm can be used as a pipeline that uses bwa and samtools:
>
>   guix package -i bamm --tune=haswell bwa samtools
>
> and to optimise the C in bamm itself too:
>
>   guix package -i bamm --tune=haswell bwa samtools bamm

So you’re saying that --tune should apply recursively, right?

> On 01/11/16 17:15, Ricardo Wurmus wrote:

[...]

>> I strongly encourage users to do two things:
>>
>> - use manifests
>> - record the current version of Guix and our local package repository
>>    when instantiating a manifest.  It only takes these two pieces of
>>    information to reproduce a software environment
> Is it possible to help automate this process somehow e.g. by checking
> if packages in GUIX_PACKAGE_PATH are within git repositories and
> reporting their statuses?

It would be nice.

As you note, there’s a design question that needs to be discussed.  On
one hand, Guix doesn’t need to know and care about how things in
$GUIX_PACKAGE_PATH were obtained, etc.  On the other hand, if Guix would
manage such external repos by itself, it would be able to give more
precise information on what’s being used and to provide more featureful
tools.

This is related to the idea of “channels” that we’ve been discussing
notably with Pjotr.

Ludo’.