Improving the usability of 'guix environment'

Improving the usability of 'guix environment'

[David Thompson]

As I use 'guix environment', I realize that I often do not want to
create an environment from the inputs of a package, but rather that I
want to create an environment from the package itself.  I didn't think
it was an issue when I did the initial development, but in practice it
has proven to be inconvenient.

For example, a development environment for guix-web requires autoconf,
automake, guile-2.0, guile-json, and libgcrypt.  To create such an
environment, I currently use a dummy package:

    ;; env.scm
    
    (package
      (name "guix-web")
      (version "0.1")
      (source ".")
      (build-system gnu-build-system)
      (native-inputs
       `(("autoconf" ,autoconf)
         ("automake" ,automake)))
      (inputs
       `(("guile" ,guile-2.0)
         ("guile-json" ,guile-json)
         ("libgcrypt" ,libgcrypt)))
      (synopsis "Web frontend for GNU Guix")
      (description "Guix-web is a web interface to the GNU Guix package
    manager written in GNU Guile Scheme and JavaScript.")
      (home-page "https://gitorious.org/guix-web/guix-web")
      (license agpl3+))

    ;; shell
    
    guix environment -l env.scm

But all of that boilerplate is unnecessary since it's not possible to
actually build the package successfully without a proper hash of the
source AFAICT.  Really, I would rather just use a simple list of
packages:

    (list autoconf automake guile-2.0 guile-json libgcrypt)

And other times it would be nice to create an ad-hoc environment from
the shell for quickly experimenting with something and not polluting a
profile:

    guix environment guile guile-sdl # let's tinker with SDL in Guile

I propose adding a new flag that indicates whether we want the packages
themselves or their inputs in the environment.  If we assume that the
default behavior is to include the packages themselves, a --inputs flag
could indicate to use the package(s) inputs instead:

    guix environment --inputs emacs

Thoughts?

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: Improving the usability of 'guix environment'

[Ludovic Courtès]

David Thompson <dthompson2@worcester.edu> skribis:

> But all of that boilerplate is unnecessary since it's not possible to
> actually build the package successfully without a proper hash of the
> source AFAICT.  Really, I would rather just use a simple list of
> packages:
>
>     (list autoconf automake guile-2.0 guile-json libgcrypt)

What about adding a case for the handling of ‘-l’ such that, if the file
evaluates to a list of packages, it does what you suggest?

> And other times it would be nice to create an ad-hoc environment from
> the shell for quickly experimenting with something and not polluting a
> profile:
>
>     guix environment guile guile-sdl # let's tinker with SDL in Guile

Right.

> I propose adding a new flag that indicates whether we want the packages
> themselves or their inputs in the environment.  If we assume that the
> default behavior is to include the packages themselves, a --inputs flag
> could indicate to use the package(s) inputs instead:
>
>     guix environment --inputs emacs

That makes sense.

In terms of UI, what about rather something keeping an interface close
to that of ‘guix package’:

  guix environment -i guile guile-sdl
  # semantically equivalent to ‘guix package -i guile guile-sdl’

Now that I think of it, we could even move -E to ‘guix package’ itself:
that would make it easy to create a scratch environment based on an
existing profile.

WDYT?

Ludo’.

Re: Improving the usability of 'guix environment'

[David Thompson]

Ludovic Courtès <ludo@gnu.org> writes:

> David Thompson <dthompson2@worcester.edu> skribis:
>
>> But all of that boilerplate is unnecessary since it's not possible to
>> actually build the package successfully without a proper hash of the
>> source AFAICT.  Really, I would rather just use a simple list of
>> packages:
>>
>>     (list autoconf automake guile-2.0 guile-json libgcrypt)
>
> What about adding a case for the handling of ‘-l’ such that, if the file
> evaluates to a list of packages, it does what you suggest?

I'm hesitant to do that, because I would also like for a list of
packages to be usable for building the environment as it's done
currently.  Only allowing a single package in a file is a limitation
right now.

>> I propose adding a new flag that indicates whether we want the packages
>> themselves or their inputs in the environment.  If we assume that the
>> default behavior is to include the packages themselves, a --inputs flag
>> could indicate to use the package(s) inputs instead:
>>
>>     guix environment --inputs emacs
>
> That makes sense.
>
> In terms of UI, what about rather something keeping an interface close
> to that of ‘guix package’:
>
>   guix environment -i guile guile-sdl
>   # semantically equivalent to ‘guix package -i guile guile-sdl’

So without the -i switch, it would behave as it does now?  Okay, but I
guess I would prefer to optimize for the common case, which in my case
would be having -i on by default.

> Now that I think of it, we could even move -E to ‘guix package’ itself:
> that would make it easy to create a scratch environment based on an
> existing profile.

I'm a bit confused about that.  Are you suggesting we merge 'guix
environment' into 'guix package'?

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: Improving the usability of 'guix environment'

[Ludovic Courtès]

David Thompson <dthompson2@worcester.edu> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> David Thompson <dthompson2@worcester.edu> skribis:
>>
>>> But all of that boilerplate is unnecessary since it's not possible to
>>> actually build the package successfully without a proper hash of the
>>> source AFAICT.  Really, I would rather just use a simple list of
>>> packages:
>>>
>>>     (list autoconf automake guile-2.0 guile-json libgcrypt)
>>
>> What about adding a case for the handling of ‘-l’ such that, if the file
>> evaluates to a list of packages, it does what you suggest?
>
> I'm hesitant to do that, because I would also like for a list of
> packages to be usable for building the environment as it's done
> currently.  Only allowing a single package in a file is a limitation
> right now.

Yeah.

>>> I propose adding a new flag that indicates whether we want the packages
>>> themselves or their inputs in the environment.  If we assume that the
>>> default behavior is to include the packages themselves, a --inputs flag
>>> could indicate to use the package(s) inputs instead:
>>>
>>>     guix environment --inputs emacs
>>
>> That makes sense.
>>
>> In terms of UI, what about rather something keeping an interface close
>> to that of ‘guix package’:
>>
>>   guix environment -i guile guile-sdl
>>   # semantically equivalent to ‘guix package -i guile guile-sdl’
>
> So without the -i switch, it would behave as it does now?  Okay, but I
> guess I would prefer to optimize for the common case, which in my case
> would be having -i on by default.
>
>> Now that I think of it, we could even move -E to ‘guix package’ itself:
>> that would make it easy to create a scratch environment based on an
>> existing profile.
>
> I'm a bit confused about that.  Are you suggesting we merge 'guix
> environment' into 'guix package'?

A possibility might be to:

  • keep ‘guix environment’ as is; after all, ‘guix environment emacs’
    really reads as “the environment for [the development of] Emacs”;

  • add a -E option to ‘guix package’ (like the -E of ‘guix
    environment’).

Example:

  # start a shell where guile and guile-sdl are available in addition to
  # what’s in ~/.guix-profile
  $ guix package -i guile guile-sdl -E $SHELL

  # start a shell where only guile and guile-sdl are available
  $ guix package -i guile guile-sdl --scratch -E $SHELL

  # start a shell in an environment which is my profile minus emacs
  # plus vim and with an upgraded zile
  $ guix package -r emacs -i vim -u zile --pure -E $SHELL

Hmm.

I’ve not completely convinced myself.

Maybe keeping it in ‘guix environment’ is wiser.  I’m not quite sure
that changing the default behavior is desirable though.

Thoughts?

Ludo’.

Re: Improving the usability of 'guix environment'

[David Thompson]

Ludovic Courtès <ludo@gnu.org> writes:

> David Thompson <dthompson2@worcester.edu> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>> I'm a bit confused about that.  Are you suggesting we merge 'guix
>> environment' into 'guix package'?
>
> A possibility might be to:
>
>   • keep ‘guix environment’ as is; after all, ‘guix environment emacs’
>     really reads as “the environment for [the development of] Emacs”;

After thinking about this more, I agree.

It seems that the real problem here is that using a string for the
'source' field of a package doesn't yield a buildable package, which
makes me feel like writing a package to encompass the dependencies is
just useless boilerplate.  If that was fixed, not only could you make an
environment from it, you could also easily pass it to 'guix build' or
'guix package', making it very useful.

>   • add a -E option to ‘guix package’ (like the -E of ‘guix
>     environment’).
>
> Example:
>
>   # start a shell where guile and guile-sdl are available in addition to
>   # what’s in ~/.guix-profile
>   $ guix package -i guile guile-sdl -E $SHELL
>
>   # start a shell where only guile and guile-sdl are available
>   $ guix package -i guile guile-sdl --scratch -E $SHELL
>
>   # start a shell in an environment which is my profile minus emacs
>   # plus vim and with an upgraded zile
>   $ guix package -r emacs -i vim -u zile --pure -E $SHELL
>
> Hmm.
>
> I’ve not completely convinced myself.
>
> Maybe keeping it in ‘guix environment’ is wiser.  I’m not quite sure
> that changing the default behavior is desirable though.

I think keeping the functionality in 'guix environment' is the best
idea, but I'm going to hold off on adding a feature like this for now.
It might not be necessary at all.

Thanks for thinking this through with me!

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: Improving the usability of 'guix environment'

[Andreas Enge]

On Tue, Feb 10, 2015 at 11:45:02AM -0500, David Thompson wrote:
>     guix environment guile guile-sdl # let's tinker with SDL in Guile

Is this not already covered by doing a "guix package -i ...", tinkering,
and a roll-back? There is one more line to type for the roll-back.
The functionality with installing inputs is much more useful as it saves
a lot of typing, and looking up which inputs are needed.

Andreas

Re: Improving the usability of 'guix environment'

[David Thompson]

Andreas Enge <andreas@enge.fr> writes:

> On Tue, Feb 10, 2015 at 11:45:02AM -0500, David Thompson wrote:
>>     guix environment guile guile-sdl # let's tinker with SDL in Guile
>
> Is this not already covered by doing a "guix package -i ...", tinkering,
> and a roll-back? There is one more line to type for the roll-back.
> The functionality with installing inputs is much more useful as it saves
> a lot of typing, and looking up which inputs are needed.

That works, but it creates more of a mess than it ought to and isn't as
automated.  I do not want to add a new generation to my profile (that
then must be explicitly GC'd later), and I want all of the environment
variables automatically setup for me somewhat like the build daemon
does.  Furthermore, 'guix environment' can create a pure environment,
where, in this example, only guile and guile-sdl things would be present
in the search paths.

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate