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.
>
>> ...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. 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.
>
>> […]
>> 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 😉
Hello!
Do you know where can we find the parameterized packages code? The
original blog that documented the developments has been down for a long
time now.
[1] https://blog.lispy.tech
The author, Sarthak, said that an issue will be opened to track the
developments, but I'm not aware if it has already been created.
Best regards,
Sergio.
