all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Improving the usability of 'guix environment'
@ 2015-02-10 16:45 David Thompson
  2015-02-10 17:25 ` Ludovic Courtès
  2015-02-10 18:17 ` Andreas Enge
  0 siblings, 2 replies; 7+ messages in thread
From: David Thompson @ 2015-02-10 16:45 UTC (permalink / raw)
  To: guix-devel

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-02-13 13:47 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-10 16:45 Improving the usability of 'guix environment' David Thompson
2015-02-10 17:25 ` Ludovic Courtès
2015-02-10 17:53   ` David Thompson
2015-02-10 21:23     ` Ludovic Courtès
2015-02-13 13:47       ` David Thompson
2015-02-10 18:17 ` Andreas Enge
2015-02-10 18:35   ` David Thompson

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.