Liliana Marie Prikler <liliana.prik...@gmail.com> writes:
Am Samstag, dem 05.04.2025 um 09:38 -0700 schrieb Ian Eure:
Hi Guixers,
I’ve seen a few patches for Emacs packages lately which have
the
form:
(package emacs-whatever
(name "emacs-whatever")
(description "Emacs interface for Whatever")
(inputs (list whatever))
(arguments
(list
#:phases
(modify-phases %standard-phases
(add-after 'unpack 'set-whatever-path
(lambda (#:key inputs #:allow-other-keys)
(emacs-substitute-variables "whatever.el"
("emacs-whatever-program"
(search-inputs-file inputs
"/bin/whatever")))))))))
Side note: the ordering of fields here looks rather displeasing.
Yes, this is a contrived example, and aggressively wrapped.
...and looking in emacs-xyz.scm, many packages do this. I
understand why this pattern exists -- making the inferior an
input
means that installing the Emacs package Just Works -- but it
also
means increased disk consumption and somewhat less user
flexibility.
On the flexibility side, it means that if you install
emacs-whatever and my-personal-whatever-fork, emacs-whatever
will
continue using the stock whatever, not your fork; making this
work
requires transforming emacs-whatever to replace the input. I
think that because this behavior is so different from how most
other operating systems work, it’s surprising, and the solution
isn’t obvious.
You obviously can still customize it to use a PATH lookup. You
are
wasting disk space if you do so.
If you don’t use the inputs to the Emacs packages, you’re wasting
disk (and bandwidth) whether you do that or not.
Alternatively, input rewriting such as the --with-input command
line
flag replace whatever with your- personal-whatever-fork and thus
do
exactly what you want.
Yes, this definitely solves it at a direct package level, but
leaves much to be desired for cases of transitive dependencies.
For example, emacs-orgit-forge depends on emacs-forge, which
depends on emacs-emacsql, which depends on mariadb and postgresql,
which none of the other packages actually use. I know there’s
been some work on recursively rewriting package trees for cases
like this, but I don’t believe any of it has merged, and I believe
this sort of thing is far out of reach for new/casual Guix users.
[…]
I’m not sure how to do that, though. I can think of a few
options:
a) Leave it as is. Don’t love it, but if there’s concensus
that
this is the right way, then okay.
b) Make packages that align better with specific usecases,
ex. emacs-emacsql-sqlite, -mysql, etc. This feels fraught to
me,
and I don’t think it works if you get emacs-emacsql-sqlite as
an
input to some other emacs-* package, but want
emacs-emacsql-mysql
as a user. Perhaps metapackages which only exist to combine
dependencies would make this a workable approach.
c) Don’t set them at all, and use the same $PATH late binding
as
is typical of other Emacs setups. This would mean that
installing Emacs packages wouldn’t Just Work, and users would
have to install the inferiors (and know what packages those
are
in) themselves.
d) Have some better policies around when to use inputs and
when
not to. This might be the most pragmatic approach, though it
means inconsistency from package to package.
e) Build a suggested package mechanism into Guix. This has
been
floated a couple times before. If it defaults to not
installing
suggested packages, but telling the user about them, this
would
be like option C, but making it easier to find which packages
you
might need; if it installs them by default, it would work like
the current setup, but give users some kind of out to avoid
the
extra bandwidth/disk usage. I don’t know how this would work
for
declarative package setups -- how would I express to Guix Home
that it should install emacs-emms with flac (for metaflac),
but
without mpg321, vorbis-tools, and mp3info?
f) Implement parametrized packages 😉
I think in practice, transformations and hopefully some day
parameters
will be a preferable solution to most of our Emacs-related
customization woes.
Indeed.
Thanks for your thoughts,
-- Ian
