Re: GNU Guix 0.8.3 released

[Ricardo Wurmus <rekado@elephly.net>]

[removed gnu-system-discuss from Cc and added guix-devel]

Marko Rauhamaa <marko@pacujo.net> writes:

> Thien-Thi Nguyen <ttn@gnuvola.org>:
>
>> () Marko Rauhamaa <marko@pacujo.net>
>> () Thu, 23 Jul 2015 16:27:44 +0300
>>
>>    I have definite use cases in mind where I might be interested
>>    in migrating to Guix. I hope to be able to investigate Guix
>>    one day.  However, it's a complex beast, and the introductory
>>    material hasn't been prepared with my use cases in mind.  So
>>    there is a bit of a hill to climb.
>>
>> What use cases do you have in mind?
>
> Here's one: I want to package a development library much like an RPM
> package. In fact, RPM would be just fine except it expects to be
> installed *by root* on *the computer*. I would need the development
> library to be installed *by a regular user* under *a directory*.

Software that has been packaged for Guix is always located in the shared
store (by default /gnu/store), but that’s an implementation detail.  As
far as users are concerned the software appears in a profile, which can
be located anywhere.

At the institute where we use Guix to allow scientists to have
independent software environments they use a default profile under
‘~/.guix-profile/’, and custom per-workflow profiles, such as
‘~/this/project/.guix-profile’.  They can thus install software as
regular users in a directory of their choosing.

> Here's another one: I have a package dependency diamond. Package A
> depends on packages B and C. B depends on package D ver 1.1. C depends
> on package D ver 1.2. I want D ver 1.2 to be able to declare binary
> compatibility with D ver 1.1 so the dependency diamond can be resolved
> by the packaging system without touching package B's dependencies.

This case is served by Guix.  At the institute we use bioinformatics
software with conflicting dependencies.  As each package has its very
own target directory in the store, independent from any other package,
installing or upgrading one package does not affect any of the other
installed packages.

(One limitation is propagated inputs, which are common in Python
modules.  A propagated input is automatically installed into the target
profile.  In this case conflicts are possible.  To avoid them these
programmes would have to be installed in separated profiles or
“directories”.)

~~ Ricardo