bug-guix
[Top][All Lists]
Advanced

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

bug#57467: [EXT] bug#57467: 'guix shell' does not honor default behavior


From: Thompson, David
Subject: bug#57467: [EXT] bug#57467: 'guix shell' does not honor default behavior when given a specific command to run
Date: Tue, 30 Aug 2022 15:26:34 -0400

So there are some competing expectations here. The status quo is that non-interactive invocations of 'guix shell' will not load a guix.scm or manifest.scm file unless explicitly told to via --file/--manifest following the "explicit is better than implicit" philosophy.  People like myself who almost exclusively invoke 'guix shell' without any arguments would expect that 'guix shell -- make' would load their guix.scm file like they're used to.  It is the latter expectation that is typically the status quo in other language environments.  For example, in Ruby land, 'bundle exec foo' runs the command 'foo' non-interactively in the context of a project and you don't have to tell it where to find the conventional Gemfile because it's the default.  Treating interactive and non-interactive invocation differently in 'guix shell' was a surprise for me.  Of course, 'guix shell -D -f guix.scm -- make' works, but it doesn't "just work."  Both viewpoints have their merits and I'm wondering if there's a way to satisfy both expectations.  Perhaps 'guix shell -- make' would load guix.scm, but 'guix shell --pure -- make', or any invocation with any flags, would not?  Or, less ideal, a new short flag that can be passed that would be the equivalent of `-D -f guix.scm` (or the manifest.scm variant) to at least make for less typing.  Personally, I think that defaulting to loading from a conventional file when no packages are specified is much more user friendly than generating an empty profile, regardless of interactive vs. non-interactive.

Thoughts?

- Dave

reply via email to

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