[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#50960] [PATCH 00/10] Add 'guix shell' to subsume 'guix environment'

From: Nicolò Balzarotti
Subject: [bug#50960] [PATCH 00/10] Add 'guix shell' to subsume 'guix environment'
Date: Sun, 03 Oct 2021 10:36:40 +0200


Vagrant Cascadian <> writes:

> On 2021-10-02, Ludovic Courtès wrote:
>> Here comes ‘guix shell’, a proposed replacement for ‘guix environment’!
> Yay!
>> ‘guix environment’ would stay around though, at least for some time,
>> probably for a long time.
>> The differences to ‘guix environment’ are:
> ...
>>   2. ‘guix shell’, without arguments, loads ‘guix.scm’ or ‘manifest.scm’
>>      from the current directory or one of its ancestors.
> This sounds a little scary to me, just implicitly importing whatever
> happens to be lying around doesn't sound very guixy...
> [...]

What about doing something like what direnv[fn:1] does?

Quoting the website:
"direnv checks for the existence of a .envrc file in the current and
parent directories. If the file exists (and is authorized), it is loaded
into a bash sub-shell and all exported variables are then captured by
direnv and then made available to the current shell."

The difference between direnv and the current approach is that if the
file has never been "authorized", before it being imported you need to
run a command (direnv allow) to authorize it.  There's the
~/.config/direnv/allow dir which stores files named with the hash of the
content of the config, and whose content is just the path of the file
(don't know why this is needed).

This allows for automatic environment ({manifest,guix}.scm) file
selection AND a it's a bit more secure (it won't run arbitrary code
residing anywhere in the directory structure).

Except for this, I'd love to see guix shell merged, it will be a major
improvement over guix environment for my use cases.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]