all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: myglc2 <myglc2@gmail.com>
To: 22695@debbugs.gnu.org
Subject: bug#22695: Binary Installation bugs and suggestions
Date: Tue, 16 Feb 2016 14:04:52 -0500	[thread overview]
Message-ID: <874md84gtn.fsf@gmail.com> (raw)
In-Reply-To: <vb5orcvy.fsf@gmail.com>

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

> myglc2 <myglc2@gmail.com> 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" <dthompson2@worcester.edu> writes:
>> [...]
>>>
>>> Don't run 'guix package -r guix'.
>>
>> Cool, please say that.
>
> +1!
>
>> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> 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 ;=)

  reply	other threads:[~2016-02-16 19:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-16 13:41 bug#22695: Binary Installation bugs and suggestions myglc2
2016-02-16 14:00 ` Thompson, David
2016-02-16 14:19 ` Ricardo Wurmus
2016-02-16 16:19   ` myglc2
2016-02-16 16:51     ` Andreas Enge
2016-02-16 17:13       ` Jookia
2016-02-16 19:09         ` myglc2
2016-02-16 20:25           ` Mathieu Lirzin
2016-02-16 19:50       ` Leo Famulari
2016-02-16 19:53         ` Leo Famulari
2016-02-16 21:34           ` Jookia
2016-02-16 17:06     ` Jookia
2016-02-16 17:32     ` Ricardo Wurmus
2016-02-16 19:04       ` myglc2 [this message]
2016-02-29 14:26         ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874md84gtn.fsf@gmail.com \
    --to=myglc2@gmail.com \
    --cc=22695@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.