guix-patches
[Top][All Lists]
Advanced

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

[bug#72406] [PATCH emacs-team WIP v3 24/24] gnu: Build all the other ema


From: Liam Hupfer
Subject: [bug#72406] [PATCH emacs-team WIP v3 24/24] gnu: Build all the other emacs-* variants.
Date: Sat, 10 Aug 2024 20:53:19 -0500

Hi Liliana,

I’m relatively new to Guix. But I’ve been converting my Emacs configuration to
use Guix with native compilation recently, so I think have a basic understanding
of this patchset.

It seems like getting binary substitutes for more Emacs variants shouldn’t
require quadrupling the number of top-level Emacs packages in Guix. I assume you
used some degree of automation to generate these, but it seems like a bit of a
pain to maintain, no? I guess you could implement some sort of CI checking if
patches for new packages include the correct variants, but it still seems like
it will lead to an increase in review burden. Seems too easy to make typos with
the variant prefix, for example. Plus there are UX issues for end users, like a
quadrupling in noise from ‘guix search emacs <package>’.

It seems like there must be a way to indicate to Cuirass to build a set of
packages with rewritten inputs, /without/ exposing those packages directly. I
believe Nix does something like this by providing an ‘emacsPackagesFor’ function
that provides an ergonomic way for users to target an Emacs variant. See Example
6 in [Adding Packages to Emacs — NixOS Manual]. Right now, Guix users have to 
use
something like ‘package-input-rewriting’ directly and figure out the list of
Emacs variants to override to their Emacs package, since not all packages use
`emacs-minimal'. For binary substitutes, the community emacs-overlay project
[tells Hydra to build] the set of Emacs packages with each common Emacs variant.

We currently don’t have a well-defined “package set” for Emacs packages to map
rewrites over like Nix, and I don’t know if that is ultimately the right
solution, but I really don’t think we should approach this by adding so many
trivial packages to the top-level package set. Imagine if we took this approach
Guix-wide for supporting another libc, for example.

Hope I didn’t misunderstand anything too much. Thanks,

—Liam


[Adding Packages to Emacs — NixOS Manual] 
<https://nixos.org/manual/nixos/stable/#module-services-emacs-adding-packages>

[tells Hydra to build] 
<https://github.com/nix-community/emacs-overlay/blob/5d6e7617e382a1e5e60103df9164a05e7351be83/flake.nix>

reply via email to

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