From: ludo@gnu.org (Ludovic Courtès)
To: David Thompson <dthompson2@worcester.edu>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] scripts: Add 'environment' command.
Date: Thu, 09 Oct 2014 21:30:43 +0200 [thread overview]
Message-ID: <87siix59cs.fsf@gnu.org> (raw)
In-Reply-To: <87oatmch5i.fsf@izanagi.i-did-not-set--mail-host-address--so-tickle-me> (David Thompson's message of "Wed, 08 Oct 2014 18:48:09 -0400")
Hey!
David Thompson <dthompson2@worcester.edu> skribis:
> The purpose of 'guix environment' is to assist hackers in creating
> reproducible development environments without polluting their package
> profile. 'guix environment' takes a package (or packages), builds all
> of the necessary inputs, and creates a shell environment to use them.
Awesome!
[...]
> By default, running 'guix environment' spawns a new $SHELL process,
> because it is usually what one would want to do. However, the '--exec'
> flag can be used to specify the command to run.
>
> Additionally, the default behavior is to prepend search paths to the
> existing environment variable values so that one has access to other
> installed software e.g. git. To clear the existing environment firstf,
> the '--pure' flag can be used.
>
> Finally, the '--load' flag can be used to read a package from a file
> instead of searching $GUIX_PACKAGE_PATH.
This looks good to me.
> From 298dcc1dd3aac49e033debeea154c91b25229c14 Mon Sep 17 00:00:00 2001
> From: David Thompson <dthompson2@worcester.edu>
> Date: Sun, 21 Sep 2014 13:40:05 -0400
> Subject: [PATCH] scripts: Add 'environment' command.
>
> * guix/scripts/environment.scm: New file.
> * Makefile.am (MODULES): Add it.
[...]
> +(define (purify-environment)
> + "Unset almost all environment variables. A small number of variables such
> +as 'HOME' and 'USER' are left untouched."
> + (for-each unsetenv
> + (filter (lambda (variable)
> + ;; Protect some env vars from purification. Borrowed
> + ;; from nix-shell.
> + (not (member variable
> + '("HOME" "USER" "LOGNAME" "DISPLAY"
> + "TERM" "TZ" "PAGER"))))
> + (map car (get-environment-variables)))))
Maybe put the list of env. vars in a global variable, say
‘%precious-variables’, and then:
(remove (cut member <> %precious-variables)
(match (get-environment-variables)
(((names . values) ...)
names)))
(My allergy to ‘car’ goes this far. ;-))
> + (display (_ "
> + -e, --exec shell command to execute"))
Perhaps make it -E, and use -e consistently with ‘guix build’? It may
be possible to reuse ‘options/resolve-packages’ for that.
> +(define %default-options
> + ;; Default to opening a new shell.
> + `((exec . ,(getenv "SHELL"))
(or (getenv "SHELL") "/bin/sh")
> +(define (build-inputs inputs opts)
> + "Build the packages in INPUTS using the build options in OPTS."
> + (with-store store
> + (run-with-store store
> + (mlet* %store-monad ((drvs (sequence %store-monad
> + (map package->derivation inputs))))
> + (mbegin %store-monad
> + (show-what-to-build* drvs
> + #:use-substitutes? (assoc-ref opts 'substitutes?)
> + #:dry-run? #f)
> + (set-build-options-from-command-line* opts)
> + (built-derivations drvs)
> + (return drvs))))))
The store should rather be kept open around (system command). Otherwise
the above derivations and their outputs could be GC’d (it should be
possible to check that by trying to run ‘guix gc -d XXX’ on one of them
from within the sub-shell.)
> +;; Entry point.
> +(define (guix-environment . args)
> + (define (parse-options)
> + (args-fold* args %options
> + (lambda (opt name arg result)
> + (leave (_ "~A: unrecognized option~%") name))
> + (lambda (arg result)
> + (alist-cons 'package arg result))
> + %default-options))
> +
> + (let* ((opts (parse-options))
> + (pure? (assoc-ref opts 'pure))
> + (command (assoc-ref opts 'exec))
> + ;; Load from file if given, otherwise search for packages.
> + (inputs (packages->transitive-inputs
> + (or (and=> (assoc-ref opts 'load) load)
> + (map specification->package
> + (pick-all opts 'package)))))
> + (drvs (build-inputs inputs opts)))
Would be good to honor --dry-run as well. It would just print what
needs to be built and exit.
Thank you!
Ludo’.
next prev parent reply other threads:[~2014-10-09 19:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-08 22:48 [PATCH] scripts: Add 'environment' command David Thompson
2014-10-09 6:44 ` Alex Kost
2014-10-09 16:50 ` Eric Bavier
2014-10-09 16:54 ` Thompson, David
2014-10-09 17:26 ` Eric Bavier
2014-10-09 19:30 ` Ludovic Courtès [this message]
2014-10-10 2:32 ` David Thompson
2014-10-10 12:09 ` David Thompson
2014-10-10 16:37 ` Ludovic Courtès
2014-10-10 18:09 ` David Thompson
2014-10-10 20:47 ` Ludovic Courtès
2014-10-10 22:16 ` David Thompson
2014-10-11 10:35 ` Ludovic Courtès
2014-10-11 12:27 ` David Thompson
2014-10-11 21:52 ` Ludovic Courtès
2014-10-12 4:43 ` Setting environment variables in .bashrc vs .bash_profile Mark H Weaver
2014-10-12 21:10 ` Ludovic Courtès
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87siix59cs.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=dthompson2@worcester.edu \
--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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).