guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guix environment


From: Pjotr Prins
Subject: Re: guix environment
Date: Tue, 16 Jun 2015 07:52:47 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Jun 15, 2015 at 03:22:55PM -0400, Thompson, David wrote:
> On Mon, Jun 15, 2015 at 3:10 PM, Pjotr Prins <address@hidden> wrote:
> > On Mon, Jun 15, 2015 at 09:10:15AM -0400, Thompson, David wrote:
> >> On Mon, Jun 15, 2015 at 2:55 AM, Pjotr Prins <address@hidden> wrote:
> >> >
> >> > Would it be OK to add some RUBY paths?
> >>
> >> What additional Ruby search paths are needed?  We already have $GEM_PATH.
> >
> > $GEM_HOME
> 
> This one doesn't make sense because it specifies where gems are to be
> installed.  Store items are immutable, so one cannot install gems into
> them.

We still provide the gem tool ;). If we set this value to something
sensible (relative to $HOME) people can still use gems. The current
default setting is not good because it does not provide isolation.

I realise this may not be a guix concern, but for guix adoption it is
good to think about these things.

> > $GEM_SPEC_CACHE
> 
> Is this a real search path or can it only point to a single cache
> directory?  If the latter, it cannot be a native search path in a
> package recipe.

Same reasoning. We want isolation between different Ruby
installations. That is what I do in that script - pick up the HASH and
create a path relative to $HOME.

If this is what every normal user needs to do, why can't we have guix
help out? Ultimately it is part of the Ruby environment we work in -
therefore it is the resposibility of the Ruby package. It does away
with needing RVM :)

We can ignore this point, but it means every user will have to work
around it. What is the point of that?

Pj.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]