Hi, On Sun, 12 Sep 2021 at 12:33, Sarah Morgensen <iskar...@mgsn.dev> wrote: > Ryan Prior <rpr...@protonmail.com> writes:
>> I've been thinking lately it would be convenient to create certain uniquely >> named execution environments on my machine. For example, I might have one >> set up with dependencies for my Python webapp & environment variables set to >> autoconnect to a Postgres server. I might have another that's got test >> dependencies and is containerized, such that it can only access the network >> & not the rest of my filesystem. Suppose I name these two "webapp" and >> "test" respectively. >> >> I picture running eg `guix env @webapp -- uvicorn main:app` to start my >> server, then `guix env @test -- pytest` to run my tests. >> >> I might write a wrapper in some scripting language that sets up this kind of >> system. Would anybody else be interested in using such a thing? Would it >> make sense to integrate this capability into Guix itself? > > I like this idea! (And adding a built-in alias from "environment" to "env" > might be worth it, too.) > > I actually use an ad-hoc version of this in my ~/.bashrc, using aliases. For > example, > > alias geg='guix environment guix --pure --ad-hoc nano git git:send-email > less help2man strace nss-certs' > > This also lets me add on any ad-hoc packages at the end, like > > geg dejagnu expect You might be interested by GUIX_EXTENSIONS_PATH which is somehow documented by this thread: :-) <https://yhetil.org/guix/86k0sekkj8....@gmail.com/> It is a not-enough known feature but really handy to: 1) define your own flavour, e.g., “guix env --options you --like“ 2) experiment for a new subcommand Once a subcommand is in Guix, it is really hard to make a CLI change so it seems better to experiment before, IMHO. :-) For an instance of this last claim: <http://issues.guix.gnu.org/38529>. > But also imagine portable environments (used, for example, for project dev > environments, checked in with the source): > > --8<---------------cut here---------------start------------->8--- > $ guix env --export @myapp-test --pure -C -f guix.scm --ad-hoc strace > coreutils > > (environment "@myapp-test" > (load '("guix.scm")) > (ad-hoc-packages '("strace" "coreutils" "findutils")) > (flags '(pure container))) > --8<---------------cut here---------------end--------------->8--- This kind of ideas is exposed here: <https://yhetil.org/guix/877dvn10ro....@dustycloud.org/> or here and there: <https://lists.gnu.org/archive/html/guix-devel/2016-07/msg00120.html> <https://lists.gnu.org/archive/html/help-guix/2018-01/msg00056.html> Thanks for the revival. :-) > Of course, this isn't entirely reproducible, as packages could change as you > update your Guix, even if you give a version spec (the same issue that exists > for manifests). So, we could pin the channel used to make the environment: > > --8<---------------cut here---------------start------------->8--- > $ guix env --export @myapp-test --pin-channels ... > > (environment "@myapp-test" > (channels (list (channel (name 'guix) > (url ...) > (commit ...))) > (load '("guix.scm")) > (ad-hoc-packages '("strace" "coreutils" "findutils")) > (flags '(pure container)))) > --8<---------------cut here---------------end--------------->8--- > > which, when evaluated, would internally do what `guix time-machine --channels > file' does. I think the correct workflow is: $ guix describe -f channels > channels.scm $ guix time-machine -C channels.scm -- subcommand --options All the best, simon
