From: Liam Hupfer via Guix-patches via <guix-patches@gnu.org>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>, 72406@debbugs.gnu.org
Cc: cox.katherine.e+guix@gmail.com, gemmaro.dev@gmail.com,
liliana.prikler@gmail.com, andrew@trop.in
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 [thread overview]
Message-ID: <87a5hjesfk.fsf@hpfr.net> (raw)
In-Reply-To: <7c4e3795db85787faee4c0818378e12869c7c471.1723300543.git.liliana.prikler@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2264 bytes --]
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>
next prev parent reply other threads:[~2024-08-11 3:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <13d156332d5c04a9ab411ee24dca58f001b6eace.1723300543.git.liliana.prikler@gmail.com>
2024-08-10 4:31 ` [bug#72406] [PATCH emacs-team WIP v3 18/24] [WIP] gnu: emacs-dvc: Build variants Liliana Marie Prikler
2024-08-10 5:02 ` [bug#72406] [PATCH emacs-team WIP v3 19/24] gnu: emacspeak: " Liliana Marie Prikler
2024-08-10 5:52 ` [bug#72406] [PATCH emacs-team WIP v3 20/24] gnu: emacs-xelb: " Liliana Marie Prikler
2024-08-10 5:54 ` [bug#72406] [PATCH emacs-team WIP v3 21/24] gnu: emacs-exwm: " Liliana Marie Prikler
2024-08-10 9:43 ` [bug#72406] [PATCH emacs-team WIP v3 22/24] gnu: emacs-exwm-x: " Liliana Marie Prikler
2024-08-10 9:43 ` [bug#72406] [PATCH emacs-team WIP v3 23/24] gnu: eless: " Liliana Marie Prikler
2024-08-10 14:15 ` [bug#72406] [PATCH emacs-team WIP v3 24/24] gnu: Build all the other emacs-* variants Liliana Marie Prikler
2024-08-11 1:53 ` Liam Hupfer via Guix-patches via [this message]
2024-08-11 6:30 ` Liliana Marie Prikler
2024-08-11 16:20 ` Liam Hupfer via Guix-patches via
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a5hjesfk.fsf@hpfr.net \
--to=guix-patches@gnu.org \
--cc=72406@debbugs.gnu.org \
--cc=andrew@trop.in \
--cc=cox.katherine.e+guix@gmail.com \
--cc=gemmaro.dev@gmail.com \
--cc=liam@hpfr.net \
--cc=liliana.prikler@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.