guix-devel
[Top][All Lists]
Advanced

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

Improving the usability of 'guix environment'


From: David Thompson
Subject: Improving the usability of 'guix environment'
Date: Tue, 10 Feb 2015 11:45:02 -0500
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)

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



reply via email to

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