[PATCH] guix environment: add a '--env-name' option

[PATCH] guix environment: add a '--env-name' option

[Cyril Roelandt]

* guix/scripts/environment.scm: add a '--env-name' option.
---
 guix/scripts/environment.scm | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index 007fde1..1d078ce 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -30,6 +30,7 @@
   #:use-module (gnu packages)
   #:use-module (ice-9 format)
   #:use-module (ice-9 match)
+  #:use-module (rnrs io ports)
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-26)
   #:use-module (srfi srfi-37)
@@ -106,6 +107,8 @@ shell command in that environment.\n"))
       --ad-hoc           include all specified packages in the environment instead
                          of only their inputs"))
   (display (_ "
+      --env-name         name of the environment, used in the prompt"))
+  (display (_ "
       --pure             unset existing environment variables"))
   (display (_ "
       --search-paths     display needed environment variable definitions"))
@@ -124,6 +127,7 @@ shell command in that environment.\n"))
   `((exec . ,(or (getenv "SHELL") "/bin/sh"))
     (substitutes? . #t)
     (max-silent-time . 3600)
+    (env-name . "guix-env")
     (verbosity . 0)))
 
 (define %options
@@ -153,6 +157,9 @@ shell command in that environment.\n"))
          (option '("ad-hoc") #f #f
                  (lambda (opt name arg result)
                    (alist-cons 'ad-hoc? #t result)))
+         (option '("env-name") #t #f
+                 (lambda (opt name arg result)
+                   (alist-cons 'env-name arg result)))
          (option '(#\n "dry-run") #f #f
                  (lambda (opt name arg result)
                    (alist-cons 'dry-run? #t result)))
@@ -226,6 +233,20 @@ packages."
               (built-derivations drvs)
               (return drvs)))))))
 
+(define (run-shell shell env-name)
+  "Run the given SHELL, adding '(ENV-NAME) ' at the start of the prompt."
+  (cond ((string=? shell "/bin/bash")
+         (let* ((directory (or (getenv "TMPDIR") "/tmp"))
+                (template  (string-append directory "/guix-file.XXXXXX"))
+                (out       (mkstemp! template)))
+           (format out "export PS1=\"(~a) $PS1\"" env-name)
+           (flush-output-port out)
+           (system (string-append "/bin/bash --rcfile " template))))
+        (else
+         (begin
+           (warning (_ "Unknown shell, will not update the prompt"))
+           (system shell)))))
+
 ;; Entry point.
 (define (guix-environment . args)
   (define (handle-argument arg result)
@@ -237,6 +258,7 @@ packages."
            (pure?    (assoc-ref opts 'pure))
            (ad-hoc?  (assoc-ref opts 'ad-hoc?))
            (command  (assoc-ref opts 'exec))
+           (env-name (assoc-ref opts 'env-name))
            (packages (pick-all (options/resolve-packages opts) 'package))
            (inputs   (if ad-hoc?
                          (packages+propagated-inputs packages)
@@ -254,4 +276,6 @@ packages."
                (show-search-paths inputs drvs pure?))
               (else
                (create-environment inputs drvs pure?)
-               (system command)))))))
+               (if (string=? command (assoc-ref %default-options 'exec))
+                   (run-shell command env-name)
+                   (system command))))))))
-- 
1.8.4.rc3

guix environment & PS1

[Ludovic Courtès]

Cyril Roelandt <tipecaml@gmail.com> skribis:

> +(define (run-shell shell env-name)
> +  "Run the given SHELL, adding '(ENV-NAME) ' at the start of the prompt."
> +  (cond ((string=? shell "/bin/bash")
> +         (let* ((directory (or (getenv "TMPDIR") "/tmp"))
> +                (template  (string-append directory "/guix-file.XXXXXX"))
> +                (out       (mkstemp! template)))
> +           (format out "export PS1=\"(~a) $PS1\"" env-name)
> +           (flush-output-port out)
> +           (system (string-append "/bin/bash --rcfile " template))))

What about this simpler idea: ‘guix environment’ would unconditionally
do:

  (setenv "GUIX_ENVIRONMENT" "t")

and then users can choose in their .bashrc to use a separate PS1 when
GUIX_ENVIRONMENT is defined.

WDYT?

Ludo’.

Re: guix environment & PS1

[Ricardo Wurmus]

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

> Cyril Roelandt <tipecaml@gmail.com> skribis:
>
>> +(define (run-shell shell env-name)
>> +  "Run the given SHELL, adding '(ENV-NAME) ' at the start of the prompt."
>> +  (cond ((string=? shell "/bin/bash")
>> +         (let* ((directory (or (getenv "TMPDIR") "/tmp"))
>> +                (template  (string-append directory "/guix-file.XXXXXX"))
>> +                (out       (mkstemp! template)))
>> +           (format out "export PS1=\"(~a) $PS1\"" env-name)
>> +           (flush-output-port out)
>> +           (system (string-append "/bin/bash --rcfile " template))))
>
> What about this simpler idea: ‘guix environment’ would unconditionally
> do:
>
>   (setenv "GUIX_ENVIRONMENT" "t")
>
> and then users can choose in their .bashrc to use a separate PS1 when
> GUIX_ENVIRONMENT is defined.

Would it be feasible to give "GUIX_ENVIRONMENT" the package name as a
value instead of just "t"?

Re: guix environment & PS1

[Thompson, David]

On Thu, Jun 25, 2015 at 7:45 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Cyril Roelandt <tipecaml@gmail.com> skribis:
>
>> +(define (run-shell shell env-name)
>> +  "Run the given SHELL, adding '(ENV-NAME) ' at the start of the prompt."
>> +  (cond ((string=? shell "/bin/bash")
>> +         (let* ((directory (or (getenv "TMPDIR") "/tmp"))
>> +                (template  (string-append directory "/guix-file.XXXXXX"))
>> +                (out       (mkstemp! template)))
>> +           (format out "export PS1=\"(~a) $PS1\"" env-name)
>> +           (flush-output-port out)
>> +           (system (string-append "/bin/bash --rcfile " template))))
>
> What about this simpler idea: ‘guix environment’ would unconditionally
> do:
>
>   (setenv "GUIX_ENVIRONMENT" "t")
>
> and then users can choose in their .bashrc to use a separate PS1 when
> GUIX_ENVIRONMENT is defined.
>
> WDYT?

+1

This is much better.

- Dave

Re: guix environment & PS1

[Thompson, David]

On Thu, Jun 25, 2015 at 8:02 AM, Ricardo Wurmus
<ricardo.wurmus@mdc-berlin.de> wrote:
>
> Would it be feasible to give "GUIX_ENVIRONMENT" the package name as a
> value instead of just "t"?

Not really, because 'guix environment' accepts any number of packages.

Up until now I have been using the $SHLVL environment variable to give
me an indication that I am within 'guix environment' sub-shell.

- Dave

Re: guix environment & PS1

[Ricardo Wurmus]

Thompson, David <dthompson2@worcester.edu> writes:

> On Thu, Jun 25, 2015 at 8:02 AM, Ricardo Wurmus
> <ricardo.wurmus@mdc-berlin.de> wrote:
>>
>> Would it be feasible to give "GUIX_ENVIRONMENT" the package name as a
>> value instead of just "t"?
>
> Not really, because 'guix environment' accepts any number of packages.

Oh, right.  I forgot about ad-hoc environments and “guix environment
-l”.

I’m mostly using “guix environment” with a single package name, and for
that purpose it would be nice if I could make the shell prompt indicate
for what package this environment was created.  I guess “t” as a value
for “GUIX_ENVIRONMENT” will have to do then.

~~ Ricardo

Re: guix environment & PS1

[Claes Wallin (韋嘉誠)]

On Thu, Jun 25, 2015 at 3:28 PM, Ricardo Wurmus
<ricardo.wurmus@mdc-berlin.de> wrote:
> Thompson, David <dthompson2@worcester.edu> writes:
>> On Thu, Jun 25, 2015 at 8:02 AM, Ricardo Wurmus
>> <ricardo.wurmus@mdc-berlin.de> wrote:
>>>
>>> Would it be feasible to give "GUIX_ENVIRONMENT" the package name as a
>>> value instead of just "t"?
>>
>> Not really, because 'guix environment' accepts any number of packages.
>
> Oh, right.  I forgot about ad-hoc environments and “guix environment
> -l”.
>
> I’m mostly using “guix environment” with a single package name, and for
> that purpose it would be nice if I could make the shell prompt indicate
> for what package this environment was created.  I guess “t” as a value
> for “GUIX_ENVIRONMENT” will have to do then.

As the variable is mostly meant for human-readable display, I think
setting it to "guix guile emacs" if those were the packages given, or
"mypackage.scm" if that was the file given, is strictly an improvement
over "t". People who just want to know if we're in a constructed
environment or not can check if the variable exists.

Re: guix environment & PS1

[Claes Wallin (韋嘉誠)]

On Thu, Jun 25, 2015 at 10:00 PM, Claes Wallin (韋嘉誠)
<gnu@clacke.user.lysator.liu.se> wrote:
> On Thu, Jun 25, 2015 at 3:28 PM, Ricardo Wurmus
> <ricardo.wurmus@mdc-berlin.de> wrote:
>> Thompson, David <dthompson2@worcester.edu> writes:
>>> On Thu, Jun 25, 2015 at 8:02 AM, Ricardo Wurmus
>>> <ricardo.wurmus@mdc-berlin.de> wrote:
>>>>
>>>> Would it be feasible to give "GUIX_ENVIRONMENT" the package name as a
>>>> value instead of just "t"?
>>>
>>> Not really, because 'guix environment' accepts any number of packages.
>>
>> Oh, right.  I forgot about ad-hoc environments and “guix environment
>> -l”.
>>
>> I’m mostly using “guix environment” with a single package name, and for
>> that purpose it would be nice if I could make the shell prompt indicate
>> for what package this environment was created.  I guess “t” as a value
>> for “GUIX_ENVIRONMENT” will have to do then.
>
> As the variable is mostly meant for human-readable display, I think
> setting it to "guix guile emacs" if those were the packages given, or
> "mypackage.scm" if that was the file given, is strictly an improvement
> over "t". People who just want to know if we're in a constructed
> environment or not can check if the variable exists.

On the other hand, this could all be done outside guix. I went ahead
and did it for myself, because I have wanted it for a couple of days.

function genv() {
  GUIX_ENVIRONMENT=$* guix environment "$@"
}

function __genv_ps1() {
  local format=$1;

  [ -v GUIX_ENVIRONMENT ] || return

  [[ -z $format ]] && format=" (%s)"

  printf "$format" "$GUIX_ENVIRONMENT"
}

... and then just chuck a $(__genv_ps1) somewhere in your favorite
$PS1 definition.

Re: guix environment & PS1

[Ludovic Courtès]

"Claes Wallin (韋嘉誠)" <gnu@clacke.user.lysator.liu.se> skribis:

> On Thu, Jun 25, 2015 at 3:28 PM, Ricardo Wurmus
> <ricardo.wurmus@mdc-berlin.de> wrote:
>> Thompson, David <dthompson2@worcester.edu> writes:
>>> On Thu, Jun 25, 2015 at 8:02 AM, Ricardo Wurmus
>>> <ricardo.wurmus@mdc-berlin.de> wrote:
>>>>
>>>> Would it be feasible to give "GUIX_ENVIRONMENT" the package name as a
>>>> value instead of just "t"?
>>>
>>> Not really, because 'guix environment' accepts any number of packages.
>>
>> Oh, right.  I forgot about ad-hoc environments and “guix environment
>> -l”.
>>
>> I’m mostly using “guix environment” with a single package name, and for
>> that purpose it would be nice if I could make the shell prompt indicate
>> for what package this environment was created.  I guess “t” as a value
>> for “GUIX_ENVIRONMENT” will have to do then.
>
> As the variable is mostly meant for human-readable display, I think
> setting it to "guix guile emacs" if those were the packages given, or
> "mypackage.scm" if that was the file given, is strictly an improvement
> over "t".

What about --ad-hoc?

People would start to have expectations about what this variable
contains, and it seems difficult to guarantee that we can always give it
a meaningful value.

Ludo’.

Re: guix environment & PS1

[Claes Wallin (韋嘉誠)]

On Mon, Jun 29, 2015 at 10:41 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> "Claes Wallin (韋嘉誠)" <gnu@clacke.user.lysator.liu.se> skribis:
>> On Thu, Jun 25, 2015 at 3:28 PM, Ricardo Wurmus
>> <ricardo.wurmus@mdc-berlin.de> wrote:


>>> I’m mostly using “guix environment” with a single package name, and for
>>> that purpose it would be nice if I could make the shell prompt indicate
>>> for what package this environment was created.  I guess “t” as a value
>>> for “GUIX_ENVIRONMENT” will have to do then.
>>
>> As the variable is mostly meant for human-readable display, I think
>> setting it to "guix guile emacs" if those were the packages given, or
>> "mypackage.scm" if that was the file given, is strictly an improvement
>> over "t".
>
> What about --ad-hoc?
>
> People would start to have expectations about what this variable
> contains, and it seems difficult to guarantee that we can always give it
> a meaningful value.

My solution just dumps all the arguments in there, let people parse
them however they like. Makes sense to me and people are free to use
it or not. I say don't over-problematize the issue.

Thanks for mentioning --ad-hoc. The first time I heard about guix
environment, I thought that something like that ought to exist. And
apparently it does! First rule of innovation: Someone probably already
did it.

Re: guix environment & PS1

[Ludovic Courtès]

"Thompson, David" <dthompson2@worcester.edu> skribis:

> On Thu, Jun 25, 2015 at 7:45 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Cyril Roelandt <tipecaml@gmail.com> skribis:
>>
>>> +(define (run-shell shell env-name)
>>> +  "Run the given SHELL, adding '(ENV-NAME) ' at the start of the prompt."
>>> +  (cond ((string=? shell "/bin/bash")
>>> +         (let* ((directory (or (getenv "TMPDIR") "/tmp"))
>>> +                (template  (string-append directory "/guix-file.XXXXXX"))
>>> +                (out       (mkstemp! template)))
>>> +           (format out "export PS1=\"(~a) $PS1\"" env-name)
>>> +           (flush-output-port out)
>>> +           (system (string-append "/bin/bash --rcfile " template))))
>>
>> What about this simpler idea: ‘guix environment’ would unconditionally
>> do:
>>
>>   (setenv "GUIX_ENVIRONMENT" "t")
>>
>> and then users can choose in their .bashrc to use a separate PS1 when
>> GUIX_ENVIRONMENT is defined.
>>
>> WDYT?
>
> +1
>
> This is much better.

I’ve pushed something like that in ‘wip-environment’; comments welcome.

I reckon it has the unfortunate property of not working out of the box
(except on GuixSD.)  I’m sure many tools these days would choose to
hard-code a fancy colored PS1; while I prefer things that work out of
the box, I’m not comfortable with hard-coding such things.

Thoughts?

Ludo’.

Re: guix environment & PS1

[Thompson, David]

On Wed, Jul 1, 2015 at 9:10 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> On Thu, Jun 25, 2015 at 7:45 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Cyril Roelandt <tipecaml@gmail.com> skribis:
>>>
>>>> +(define (run-shell shell env-name)
>>>> +  "Run the given SHELL, adding '(ENV-NAME) ' at the start of the prompt."
>>>> +  (cond ((string=? shell "/bin/bash")
>>>> +         (let* ((directory (or (getenv "TMPDIR") "/tmp"))
>>>> +                (template  (string-append directory "/guix-file.XXXXXX"))
>>>> +                (out       (mkstemp! template)))
>>>> +           (format out "export PS1=\"(~a) $PS1\"" env-name)
>>>> +           (flush-output-port out)
>>>> +           (system (string-append "/bin/bash --rcfile " template))))
>>>
>>> What about this simpler idea: ‘guix environment’ would unconditionally
>>> do:
>>>
>>>   (setenv "GUIX_ENVIRONMENT" "t")
>>>
>>> and then users can choose in their .bashrc to use a separate PS1 when
>>> GUIX_ENVIRONMENT is defined.
>>>
>>> WDYT?
>>
>> +1
>>
>> This is much better.
>
> I’ve pushed something like that in ‘wip-environment’; comments welcome.
>
> I reckon it has the unfortunate property of not working out of the box
> (except on GuixSD.)  I’m sure many tools these days would choose to
> hard-code a fancy colored PS1; while I prefer things that work out of
> the box, I’m not comfortable with hard-coding such things.
>
> Thoughts?

I agree with you.  I'd rather not hard-code some fancy PS1.

- Dave

Re: guix environment & PS1

[Claes Wallin (韋嘉誠)]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On Jul 1, 2015 4:02 PM, "Thompson, David" <dthompson2@worcester.edu> wrote:
> On Wed, Jul 1, 2015 at 9:10 AM, Ludovic Courtès <ludo@gnu.org> wrote:

> > I reckon it has the unfortunate property of not working out of the box
> > (except on GuixSD.)  I’m sure many tools these days would choose to
> > hard-code a fancy colored PS1; while I prefer things that work out of
> > the box, I’m not comfortable with hard-coding such things.
> >
> > Thoughts?
>
> I agree with you.  I'd rather not hard-code some fancy PS1.

Leaving power PS1 to power users is the reasonable thing to do. Colored
path and username etc is fine, but every user has their own ideas on where
git branch and other things ought to go.

[-- Attachment #2: Type: text/html, Size: 958 bytes --]