[Bio-packaging] testing out guix

[pjotr.public66 at thebird.nl]

On Wed, Jun 10, 2015 at 09:45:23AM +1000, Ben Woodcroft wrote:
> Good. But the question of versions is I think more fundamental than
> the fact sometime software X requires an old version of software Y.
> Perhaps I care about this more than I should, but sometimes I prefer
> to use old versions for the sake of scientific control - if I used
> version 1 on sample A last year and now I want to analyse sample B
> but only the newer version 2 is installed, then I'm stuck. Sometimes
> older software is better, even if it is buggier and provides no
> extra features.

Right. Since Guix sits in git you can tag a SHA value with your
exercise/analysis. Next time you want to run it, go back in time. Guix
does not care which version of guix and tree you run - and you may
even still get binary installs (or create your own cache) since every
version of software and related dependencies are unique.

You can also use a Docker image for that - but Guix is much cheaper to
manipulate and to move around :)

> >>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
> This sounds excellent. Perhaps combined with a module system and
> this might solve the versioning issue I mention above, with 1
> profile = 1 module?

Yep. Better than modules: you can mix and match profiles.

Pj.

--