bug#22695: Binary Installation bugs and suggestions

[myglc2]

Ricardo Wurmus <address@hidden> writes:

> myglc2 <address@hidden> writes:
>
>> The use case I had in mind is that sysadmin uses Guix to provide a
>> specific Guix environment to support 1 or more "dumb" application users
>> (e.g, provide a stable specific version of R to a project team for the
>> duration of the project). In this case sysadmin does not want to burden
>> the team members with learning Guix.
>>
>> Do we support such a case?
>
> Yes.  I have been doing this for our cluster users for months before we
> could make the changes in our environment that were needed to let users
> manage their profiles by themselves.
>
> We currently use Guix for shared per-group profiles, individual per-user
> profiles, and per-project profiles.
>
> You can install packages into a custom profile by using the “-p” flag,
> e.g.
>
>     guix package -p /path/to/shared/profile \
>                  --install glibc-utf8-locales r r-genomation
>
> Users would then have to add something like this to their
> ~/.bash_profile:
>
>     eval $(guix package -p /path/to/shared/profile --search-paths=prefix)
>
> or just add the result of the command in parentheses to the
> ~/.bash_profile.  This would prepend the “bin” directory of the profile
> to the PATH and set other environment variables that are needed.
>
> Then they could use an unchanging version of the “genomation” package
> from within R, as defined in that profile.  (In the long run it would
> make more sense to instantiate profiles using manifest files.)

Fantastic. You have just described one of the fantasy use cases that
have propelled me to spend a few weeks learning first NixOS and now
Guix.

> Slightly off-topic: note that in this case installing R packages via
> ‘install.packages(...)’ is discouraged.  Some R packages link with
> system libraries and unless you’re also adding the compiler toolchain to
> your profile you would end up with binaries that are linked with the
> system libc and thus cannot successfully be loaded by the R in your
> profile, which is linked with libc from the Guix store.
>
> I suggest going full Guix instead of mixing ‘install.packages(...)’ with
> Guix stuff.  We have importers for CRAN and bioconductor, so packaging R
> packages for Guix is usually really simple.  (I’ve used the importer to
> generate package expressions for all of CRAN, but since I’m not using
> them all I haven’t yet found motivation to submit patches for them.)

I have bite marks from the same dog. I agree this is the way to go.

>>>> 4) What do we mean by, 'The guix package must remain available in root’s
>>>>    profile, or it would become subject to garbage collection—in which
>>>>    case you would find yourself badly handicapped by the lack of the
>>>>    guix command.'
>>>>
>>>>    What does root have to do to assure that 'The guix package remains
>>>>    available'?
>>>
>>> I think this means that the root user should not uninstall guix with
>>> guix.
>>
>> "Thompson, David" <address@hidden> writes:
>> [...]
>>>
>>> Don't run 'guix package -r guix'.
>>
>> Cool, please say that.
>
> +1!
>
>> Ricardo Wurmus <address@hidden> writes:
>> [...]
>>>> 5) We should tell root how to verify that the installation was
>>>>    successful.  If 'make guix-binary.system.tar.xz' is intended to do
>>>>    this, we need to explain where to run it and how to verify the
>>>>    result.
>>>
>>> The install was successful if “guix package -i hello” (or similar)
>>> works.
>>
>> Cool, lets tell them to do that.
>
> +1!
>
> Would you be willing to send a patch?  (I’m pretty sure I’ll forget
> doing this myself.)

Will do once I get my Guix space suit fully inflated ;=)