Re: Guix CLI, thoughts and suggestions
On Mon, Jan 15, 2024 at 11:24:29AM -0800, Ian Eure wrote: > Greetings, > > As I’ve been learning Guix, one of the things I’ve found somewhat unpleasant > is the lack of consistency within the guix CLI tool. It feels a bit > Git-like, with not much consistency, commands that non-obvioulsy perform > more than operation, related commands in different places in the tree, etc. > > Just so you know where I’m coming from: I’ve found that compliex CLI tooling > benefits from organization and consistency. The Linux ip(8) command is a > good example of this kind of organization: to add an IP address, you use `ip > address add'. To show address, `ip address show', and to remove one `ip > address del'. When options are needed, they get added after the verb or > branch in the verb tree; the final verb may take positional arguments as > well as --long or -s (short)-form options. > > Some examples of where I think Guix could do better. This is an > illustrative list, not an exhaustive one. > > Inconsistent organization > = > > Most package-related commands are under `guix package', but many are sibling > commands. Examples are `guix size', `guix lint', `guix hash', etc. > > > Inconsistency between verbs and options > === > > Some verbs are bare-word positional arguments, and others are flags to > related verbs. IMO, this is the biggest problem, and makes it very > difficult to find all the things the CLI can do. `guix package' is a major > offender in this area, as it mixes verbs and verb-specific options into the > same level. For example, installing a package is `guix package -i foo' > rather than `guix package install foo', removing is `guix package -r foo' > rather than `guix package remove foo', and listing installed packages is > `guix package -I' rather than `guix package installed' (or similar). > > This means that users can express commands which *seem* like they should > work, but do not. For example `guix package -i emacs -r emacs-pgtk -I' > represents a command to 1) install emacs 2) remove emacs-pgtk 3) list > installed packages (which would verify the previous two operations > occurred). This is a valid command within the accepted organization of > `guix package', and doesn’t cause an error, but doesn’t work: the install > and remove steps are ignored. I found this part surprising. I know you can chain together -i and -r, but I had never tried adding -I to the list also, and it makes sense to me that it should be able to be chained in also. > A thing I’ve found throughout my career is > that designing systems so it’s *impossible* to represent unsupported, > nonsensical, or undefined things is an extremely valuable technique to avoid > errors and pitfalls. I think Guix could get a lot of mileage out of > adopting something similar. > > This causes a related problem of making it impossible to know what options > are valid for what verbs. Will `guix package --cores=8 -r emacs' remove the > package while using eight cores of my system? Will `guix system -s i686 > switch-generation 5' switch me to a 32-bit version of generation 5? If > verbs are organized better, and have their own options, this ambiguity > vanishes. > > > More inconsistency > == > > Other parts of guix have the opposite problem: `guix system docker-image' > probably ought to be an option to `guix system image' rather than a separate > verb. > > > Inconsistency between similar commands > == > > There are generations of both the system (for GuixSD) and the user profile, > however, they work differently. For the system, there’s `guix system > list-generations' and `guix system switch-generation', but for the user > profile, you need `guix package --list-generations' and `guix package > --switch-generation=PATTERN'. Additionally, no help is available for either > of the system commands: `guix system switch-generations --help' gives the > same output as `guix system --help' -- no description of the supported ways > of expressing a generation are available. > > > Flattened verbs > === > > Related, the generation-related commands under `guix system' ought to be one > level deeper: `guix system generation list', `guix system generation switch' > etc. > > > Repeated options > > > Many commands (`guix package', `guix system', `guix build', `guix shell') > take -L options, to add Guile source to their load-path. This probably ought > to be an option to guix itself, so you can do `guix -L~/src/my-channel build > ...'. > > > Suggestions > === > > All commands should be organized into a tree of verbs. > > Verbs should have common aliases (`rm' for `remove', etc). > > Verbs should be selected by specifying the minimum unambiguous substring. > For example `guix sys gen sw' could refer to `guix system generation > switch'. > > Options should
Re: Commit Access: Sharlatan Hellseher
> Just my 2 cents, I imagine every person here has their own workflow. I personally don't have any yet (and I assume I'm not the only one) so I'm really thankful for your snippet. Cheers Bost
Guix deploy --keep-going equivalent for machine connection failures
Hi all, When running guix deploy with a list of machines, the command will fail if any of the machines are unreachable. I use Guix deploy from a central machine to update the devices on my LAN, including laptops, which aren't guaranteed to be on. I'm also not terribly worried about keeping every single device updated in perfect synchronicity. I think it would be useful to have a CLI flag that would continue the deployment even if we fail to connect to one of the machines. At present this can be worked around by commenting out entries on the list, but this requires a) Already knowing what machine is offline b) Remembering to uncomment it later when the machine goes back online c) Generally feels "ugly" in a way that most Guix commands don't. d) Makes version control a pain The default behavior should stay as is, I imagine, since one of the main uses of guix deploy is deploying an interconnected cluster of machines that probably would not appreciate being partially upgraded. Another option worth considered is adding a `'can-connection-fail?' (default: #f)` to either `machine` or `machine-ssh-configuration`. (Probably machine since it would also allow for digitalocean deployments.) This would let me mix a list of "core machines" that I definitely want upgraded in a deployment (NAS, etc), while still having secondary machines that I'm not particularly concerned about upgrading. When running a deployment, there are effectively 3 options for how I could want the deployment to go for machines X, Y, and Z: a) X, Y, and Z must all be deployed together <--- Supported b) X must be deployed, but Y and/or Z can fail<--- can-connection-fail? setting c) X, Y, and/or Z can fail<--- --keep-going-but-for-machines-I-don't-know-what-to-call-this Anyone have thoughts on this? Thanks, Richard Sent
Re: [swh-devel] Call for public review - SWH Nix/GNU Guix stack
Hello, This is very exciting work, thanks everyone! "Antoine R. Dumont (@ardumont)" writes: > FWIW, in the "new" lister [1] implementation, there are a bunch of extra > computations done [1] to try and resolve those situations. It's trying > to fetch more information from upstream server (e.g. crates urls which > ends in /download, ...) now. It's probably not exhaustive though. > > [1] > https://gitlab.softwareheritage.org/swh/devel/swh-lister/-/blob/master/swh/lister/nixguix/lister.py?ref_type=heads I was just looking over some of the new results and noticed that crates are being treated as ‘content’ rather than ‘tarball-directory’. E.g.: https://webapp.staging.swh.network/browse/content/sha1_git:e05b33b2d3b40254ceaaa5fe4c501d1b15c75ea6/?origin_url=https://crates.io/api/v1/crates/diff/0.1.12/download Is that because the changes you describe were done after the staging data was loaded or is it a bug? -- Tim
Collecting Guix talks at FOSDEM
Hi all, We're planning to put up a blog post about Guix (and Guix-related) talks at FOSDEM [0]. I've collected all the talks that that are about Guix (or connected areas). If I've missed any Guix related talks please tell me so I can add them to the blog post: - Declarative and Minimalist Computing track - This track [1] has: - RISC‐V Bootstrapping in Guix and Live‐Bootstrap - Ekiatz Zárraga - Sunday: 11:20 - 11:40 - https://fosdem.org/2024/schedule/event/fosdem-2024-1755-risc-v-bootstrapping-in-guix-and-live-bootstrap/ - Self-hosting and autonomy using guix-forge - Arun IsaaC - Sunday: 11:40 - 12:00 - https://fosdem.org/2024/schedule/event/fosdem-2024-2560-self-hosting-and-autonomy-using-guix-forge/ - Spritely, Guile, Guix: a unified vision for user security - Christine Lemmer-Webber - Sunday: 12:00 - 12:25 - https://fosdem.org/2024/schedule/event/fosdem-2024-2331-spritely-guile-guix-a-unified-vision-for-user-security/ Other tracks - - Making reproducible and publishable large-scale HPC experiments - Philippe SWARTVAGHER - Saturday: 10:30 - 11:00 - https://fosdem.org/2024/schedule/event/fosdem-2024-2651-making-reproducible-and-publishable-large-scale-hpc-experiments / - Supporting architecture psABIs with GNU Guix. - Efraim Flashner - Sunday: 14:30 - 14:55 - https://fosdem.org/2024/schedule/event/fosdem-2024-2927-supporting-architecture-psabis-with-gnu-guix/ Connected 'Guile/Scheme' interest -- - Scheme in the Browser with Guile Hoot and WebAssembly - Robin Templeton - Sunday: 11:00-11:20 - https://fosdem.org/2024/schedule/event/fosdem-2024-2339-scheme-in-the-browser-with-guile-hoot-and-webassembly/ Thanks, Steve [0] Ludo's post from last year: https://guix.gnu.org/en/blog/2023/meet-guix-at-fosdem-2023/ [1] https://fosdem.org/2024/schedule/track/declarative-and-minimalistic-computing/
Re: Golang check phase skipping some tests?
On 2024-01-14 22:12:38 +0100, Troy Figiel wrote: > Hi everyone, > > When looking into the Go build system, I noticed the default check phase > runs (invoke "go" "test" import-path), which only runs the tests in the > root directory of the source. Running the tests in all subdirectories > would require something like this instead: > > --8<---cut here---start->8--- > (define* (check #:key tests? import-path #:allow-other-keys) > "Run the tests for the package named by IMPORT-PATH." > (when tests? > (invoke "go" "test" (string-append import-path "/..."))) > #t) > --8<---cut here---end--->8--- > > For example, if the -v flag is added (which might be a better default?) > to the check phase of go-github-stretchr-testify, it can be seen that > only `TestImports' runs, none of the tests in assert, http, etc. > However, the source code in these subdirectories is still recursively > copied to out during the install phase. > > Is this desired behaviour? I assumed it isn't, because it looks like we > are skipping a lot of tests during the check phase. However, I might > also simply be overlooking something here as I am new to packaging > Golang with Guix. I tend to agree (on both accounts). I am not aware of anything Guix specific here that would prevent it, but maybe someone from golang team will chime in. Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
