[Bio-packaging] testing out guix

[Pjotr Prins]

On Tue, Jun 09, 2015 at 03:58:49PM +0200, Ricardo Wurmus wrote:
> > I'm thinking that the mailing list method is foreign to most 
> > bioinformaticians so a github for collating them would be useful, yeh.
> 
> I'll see if maybe I can set up a regularly synced github mirror for
> contributors who are uncomfortable with sending patches to the mailing
> list.  (I prefer this method over Github pull requests, but I realise
> others have a different opinion on this.)

Great.

It is just a threshold. I think when people do regular contributions
they'll learn how to do that by themselves. I am all for low
threshold (initially). Let everyone contribute and we take it from
there.

> > One thing that I'm trying to understand. Is there any way you can 
> > configure guix to be able to serve different versions of the same 
> > software a la module systems on clusters? I'm told there's a video at 
> > http://www.gnu.org/software/guix/ where at the end someone asks this 
> > question and the presenter effectively says no to this.
> 
> Yes, it is possible to define package variables for different versions
> of one software.  Currently in bioinformatics.scm we have two versions
> of Samtools, for example.  

And there are two Pythons and two Rubies - and there will be at least
three soon.

> It is possible to have more than two
> versions, but there would need to be a good reason to keep them upstream
> in GNU Guix.  It is totally feasible, though, to have a separate
> repository with as many legacy versions as you wish.  In fact, I
> maintain a repository with recipes that I don't intend to upstream to
> GNU Guix, which contains various legacy versions that are of interest to
> our users here, but are not suitable for submission to Guix upstream.

Maybe the bioinformatics repo can cater for that too. We cherry-pick
what goes upstream.

But (actually) I think it should be based on user's needs and
dependencies. We do have older software that depends (for example) on
a specific version of an underlying library or tool. Why would Guix
not cater for that? With Debian I had this ongoing argument where the
package maintainers would say we had to do an upstream fix. Truth is,
in bioinformatics the upstream authors may have disappeared :).

> To install multiple versions you have to consider clobbering.  Samtools
> for example provides $out/bin/samtools in version 0.1.19 as well as in
> 1.1, so you cannot install both of these binaries into the very same
> profile.  With Guix you can target profiles simply by passing "-p
> /path/to/new/profile" to "guix package", e.g.:
> 
>     guix package -p my-pipeline -i samtools-0.1.19 macs

Exactly. I actually always have a Ruby 1.8.7 profile for some legacy
stuff which contains $HOME/opt/ruby-1.8.7/bin/ruby

Pj