all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Thompson, David" <dthompson2@worcester.edu>
To: Andreas Enge <andreas@enge.fr>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: The future of 'guix environment'
Date: Wed, 30 Aug 2017 21:28:13 -0400	[thread overview]
Message-ID: <CAJ=Rwfb9TNLGD0qVHHb4MtfLgt2eVNRA9ZTUjdXjZHDhH5P5Rw@mail.gmail.com> (raw)
In-Reply-To: <20170830155634.GB2248@jurong>

Thanks for the feedback, everyone.  I'm going to try to address what
everyone has been discussing.

宋文武, I agree with Andreas that making a new command is undesirable and
would just lead to confusion.  I think a single tool can support the
major use cases well.  I'd go so far as to say that I will have failed
if two commands are necessary.  We can always add subcommands to 'guix
environment' itself, if that turns out to be better for usability.  We
will see.

As for a 'guix environment up' command, I think that's worth thinking
about but I'm going to avoid thinking about it too much because we're
still quite a ways off from being able to make this happen.  My
general feeling is the same as Ricardo's, though, that 'guix
environment' should just spawn the services automatically and there
would have to be some notion of "attaching" to an existing session.
This topic deserves a whole separate thread when the time comes.

Ricardo, you are correct that we would lose the ability to use the
guix.scm file for both 'guix environment' and 'guix build'.  In
practice I don't actually use my guix.scm file this way, so I think
it's worth breaking, but maybe you (or someone else) actually uses
this and we should think more about it?

I wasn't very clear about whether ephemeral or cached would be the new
default.  I don't think there is one default for all cases, I think
it's more context sensitive.  When the user specifies --load, I think
caching should be the default because loading such a file means that
you are working on a project for which you'd like a persistent
environment.  When the user specifies ad-hoc packages, caching would
be disabled because most likely they are running a one-off job.  For
example, 'guix environment ruby -- irb' should spawn a Ruby REPL,
discarding the environment when the user exits.  'guix environment
--load=guix.scm' would check for a cached profile, use it if it is
there, otherwise build the profile and cache it for next time.  'guix
environment', without --load or any packages specified, would be
equivalent to 'guix environment --load=guix.scm'.  A little
"convention over configuration" will greatly improve usability, I
think.  There's really only 2 major use cases, and I want those to
work without having to fiddle with a bunch of command line flags.  All
the underlying flags will still be there to fiddle with for those who
are interested.

- Dave

  reply	other threads:[~2017-08-31  1:28 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-30 13:22 The future of 'guix environment' Thompson, David
2017-08-30 15:11 ` 宋文武
2017-08-30 15:33   ` Leo Famulari
2017-08-30 15:43   ` Ricardo Wurmus
2017-08-31 15:00     ` Ludovic Courtès
2017-08-30 15:56   ` Andreas Enge
2017-08-31  1:28     ` Thompson, David [this message]
2017-09-01  3:57       ` Christopher Allan Webber
2017-09-01 13:15         ` Thompson, David
2017-09-02 21:06         ` Ludovic Courtès
2017-09-03  7:15           ` Jan Nieuwenhuizen
2017-09-05 12:42             ` Thompson, David
2017-09-05 14:34               ` Ludovic Courtès
2017-08-30 15:52 ` Andreas Enge
2017-08-31  7:18 ` Jan Nieuwenhuizen
2017-08-31 13:28   ` Thompson, David
2017-09-01 11:50     ` Jan Nieuwenhuizen
2017-09-01 12:08       ` Ricardo Wurmus
2017-09-01 12:25         ` Jan Nieuwenhuizen
2017-09-01 13:13       ` Thompson, David
2017-08-31 15:16 ` Ludovic Courtès
2017-09-01  0:29   ` Thompson, David
2017-09-02 21:09     ` Ludovic Courtès
2017-09-01  3:52 ` Christopher Allan Webber

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='CAJ=Rwfb9TNLGD0qVHHb4MtfLgt2eVNRA9ZTUjdXjZHDhH5P5Rw@mail.gmail.com' \
    --to=dthompson2@worcester.edu \
    --cc=andreas@enge.fr \
    --cc=guix-devel@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.