Re: Emacs dependent package input question
Hi Ian, On Sat, 05 Apr 2025 at 09:38, Ian Eure wrote: > a) Leave it as is. Don’t love it, but if there’s concensus that > this is the right way, then okay. Somehow, the consensus has been to have “maximally” featured packages – roughly speaking – and use -minimal when not. For instance, Alpine does the contrary: emacs is “minimal” and then emacs-gtk3, emacs-nox, etc. Although I personally prefer Alpine approach, until now, this approach does not seem floating in Guix atmosphere. :-) Somehow, the closure is much too large, IMHO. > 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. I’ve never read the Alpine policy but I guess they have one. :-) > 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. To me the only question is about the default. Is emacs-emms “maximally” featured thus compiled with most – if not all – the backends? Or is emacs-emms “minimally” featured thus not really working out-of-the-box? > 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? Somehow, it would rely on parameterized packages as mentioned elsewhere in the thread, no? Well, that’s interesting but how we can learn with Gentoo’s experiment, this approach leads to some combinatorial issues: It would be hard to provide substitutes or to have some guarantee that some combinations of parameters indeed build together or work together. Hum, good question! :-) All in all, you raise a good topic… and it will be difficult to change the current status quo, IMHO. Cheers, simon
Re: Emacs dependent package input question
Hi, >making this work requires transforming emacs-whatever to replace the >input. Yeah, but that's what you have to do with anything else in guix. You just need to invoke guix ... --with-input=mpg123=someother or use options->transformation in a guix home scm file for the same effect. It does replace any transitive dependencies with that name, too. (For comparison, I currently have 20 such options->transformations calls--7 of those for emacs packages) >Another example is emacs-plantuml-mode, which has plantuml as an >input, which has icedtea as an input -- meaning an install of the >Emacs package comes with a whole Java runtime. Well, if it doesn't work without then that is exactly how it's supposed to be. That Java runtime will be deduplicated anyway, though. It's also just a *specific* plantuml version that is supported by emacs-plantuml (since they communicate, they have to use a common protocol). And plantuml depends on the Java version that it was tested with. And different openjdk major versions ARE (slightly) incompatible, for example. So openjdk *absolutely* should be a regular input of plantuml, and plantuml should be automatically wrapped so it does use that. For the same reason, plantuml should be a regular input of emacs-plantuml. >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. In the end it depends on what kind of program the other program is. If it's an implementation detail (something conceptually inside the black box of the emacs-* package) then it should be a regular input. It should NOT be taken from PATH or in any other way late bound then. If we did late bind it that would just cause compatibility and usability problems. But if it's just a loose optional program that would conceptually be outside the black box of the emacs-* package and be in its own box, then it should just be picked up from PATH--or in an ideal world it would be activated via a dbus service in the first place, with an official interface (!!). Those are fundamentally different things in system design. It's not specific to emacs or anything. The disk space stuff would be better solved by parametrized packages. But that kind of dependency combinatorics would have fallout. It would cause packages not to build--see Gentoo USE flags and what happens when you use those (breakage... so much breakage)--and you would have a (exponentially) bigger amount of substitutes. I say that even though I'm low key bothered by the large amount of disk space that guix needs for stuff that I will never use. But there are tradeoffs. Optimizing for disk space would open another can of worms (combinatorial explosion). As it is, I just buy a way bigger drive than I would need for my data, for an extra $40. And if I wanted programs to invoke random executables I happen to have lying around, I could just use Debian. I was there--and it's not reliable to have this kind of global namespace in the wild west that is the free software ecosystem (this kind of thing creates a massive amount of inofficial interfaces--guess how long those are stable if none of the involved people know that the interfaces exist).
Re: Emacs dependent package input question
Sarthak Shah writes: > I've moved domain names, the final post is at > https://blog.coldboot.org/parameterized-packages-the-project-completion-update.html > You can find code for the project in this repository: > https://notabug.org/cel7t/guix-parameters > Additionally, the project completion report: > https://github.com/matchcase/parameterized-packages.org I see. That's reassuring, I was worried that your work could get lost! > I haven't been able to make an issue for this project because I'll need to > update bits of the code to ensure that it is working smoothly before > creating an issue and unfortunately I'm a bit occupied at the moment as I'm > writing my graduation thesis. Yes, I remember you mentioned that on a previous mail. I wish you the best in your dissertation defense! If you need help updating the code let us know, I'm sure there are quite a few of us that will gladly review your work. Best regards, Sergio.
Re: Emacs dependent package input question
Hi Sergio,
I've moved domain names, the final post is at
https://blog.coldboot.org/parameterized-packages-the-project-completion-update.html
You can find code for the project in this repository:
https://notabug.org/cel7t/guix-parameters
Additionally, the project completion report:
https://github.com/matchcase/parameterized-packages.org
I haven't been able to make an issue for this project because I'll need to
update bits of the code to ensure that it is working smoothly before
creating an issue and unfortunately I'm a bit occupied at the moment as I'm
writing my graduation thesis.
Best,
Sarthak.
On Sun, 6 Apr 2025, 19:16 Sergio Pastor Pérez,
wrote:
> Liliana Marie Prikler 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.
>
Re: Emacs dependent package input question
Liliana Marie Prikler 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.
Re: Emacs dependent package input question
On 2025-04-05 16:55, Ian Eure wrote: >> I'd argue sometimes it's indeed the better solution, especially >> when >> the core of the package needs the binary to work properly, not >> when it's >> an additional option or feature. I'll refer to that as >> "essential >> binary" in the rest. > > I appreciate this line of thinking, but suspect that whether a > binary is essential or not depends on the user’s usecase, which is > unknowable at package build time. For a user using EMMS to play > MP3s, flac isn’t essential, and mpg321 is; for someone using it to > play FLACs, the inverse is true. > >> (This is the case where not having the binary is absurd because >> it >> renders the emacs package unusable). > > I think it’s important to distinguish between "unusable" and "not > usable unless the user takes some action." In those cases, maybe we could have -minimal variants? >> I agree this is nice, but maybe it's enough to do that in Emacs >> packages >> themselves (ensuring they suggest the missing binary when it's >> not >> found) rather than in Guix Home itself. > > I also like this idea; do you have an idea what an implementation > for that would look like? Presumably upstream package authors > wouldn’t want Guix-specific stuff in packages that need to work on > any OS/distro. Indeed, I don't mean plainly writing "Guix profile" in Emacs packages, but ensuring for instance that we have a proper error message explaining that the package is not in the PATH. I guess something like "Unable to find xxx, ensure it is installed on your system." is clear enough. A recent example that happened to me (not a binary though but a guix-related bug): https://github.com/anticomputer/age.el/issues/15 was fixed with https://github.com/anticomputer/age.el/pull/16/commits/a1c9d0a7911e603e6574daf1ee6d602d1e932842 Not writing "Guix" anywhere, but it makes it clear that something is missing on the system. -- Best regards, Nicolas Graves
Re: Emacs dependent package input question
Am Samstag, dem 05.04.2025 um 16:27 -0700 schrieb Ian Eure: > 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. Have you tried --with-input=postgresql=your-postgresql? Because I think it ought to do exactly that. (While obviously also rebuilding much of your Emacs tree) Cheers
Re: Emacs dependent package input question
Hi Nicolas, Nicolas Graves writes: On 2025-04-05 09:38, Ian Eure wrote: Hi Ian, thanks for this discussion. This is my (d) (better policy proposition): a) Leave it as is. Don’t love it, but if there’s concensus that this is the right way, then okay. I'd argue sometimes it's indeed the better solution, especially when the core of the package needs the binary to work properly, not when it's an additional option or feature. I'll refer to that as "essential binary" in the rest. I appreciate this line of thinking, but suspect that whether a binary is essential or not depends on the user’s usecase, which is unknowable at package build time. For a user using EMMS to play MP3s, flac isn’t essential, and mpg321 is; for someone using it to play FLACs, the inverse is true. (This is the case where not having the binary is absurd because it renders the emacs package unusable). I think it’s important to distinguish between "unusable" and "not usable unless the user takes some action." 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? I agree this is nice, but maybe it's enough to do that in Emacs packages themselves (ensuring they suggest the missing binary when it's not found) rather than in Guix Home itself. I also like this idea; do you have an idea what an implementation for that would look like? Presumably upstream package authors wouldn’t want Guix-specific stuff in packages that need to work on any OS/distro. -- Ian
Re: Emacs dependent package input question
Liliana Marie Prikler 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
Re: Emacs dependent package input question
On 2025-04-05 09:38, Ian Eure wrote: Hi Ian, thanks for this discussion. This is my (d) (better policy proposition): > a) Leave it as is. Don’t love it, but if there’s concensus that > this is the right way, then okay. I'd argue sometimes it's indeed the better solution, especially when the core of the package needs the binary to work properly, not when it's an additional option or feature. I'll refer to that as "essential binary" in the rest. (This is the case where not having the binary is absurd because it renders the emacs package unusable). > 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. IMO this is the best solution when it's not an "essential binary" : Maybe when the package properly signals the absence of the desired input to the user AND the package behaving properly as soon as it's in a profile is enough (and we wouldn't need to ensure inputs in this case). This means that we could participate in emacs packages by improving their management of missing binaries, so that we can ensure normal guix use with smaller profiles. > 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? I agree this is nice, but maybe it's enough to do that in Emacs packages themselves (ensuring they suggest the missing binary when it's not found) rather than in Guix Home itself. In summary : Is the input essential to the core functionality of the emacs package? + Yes: (a) + No: Is the package signalling the absence of its input in a Guix-understandable way? Does adding the input fix the issue? - Both yes : (c) - At least a No: Submit a patch to the upstream package to ensure both yes. -- Best regards, Nicolas Graves
Re: Emacs dependent package input question
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 😉
I think in practice, transformations and hopefully some day parameters
will be a preferable solution to most of our Emacs-related
customization woes.
Cheers
Emacs dependent package input question
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")
...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.
On disk space, it means that many packages come with inputs to
serve many possible usecases, whether those are relevant or not.
One fairly trivial example: emacs-emms has inputs for mpg321,
mid3v2, ogg123, ogginfo, and opusinfo. My music library is 100%
FLAC, so these programs are never used, but consume disk on my
Guix install. And on the other hand, I often use EMMS to play
videos, but mpv *isn’t* an input, so this usecase is broken out of
the box.
Another example is emacs-plantuml-mode, which has plantuml as an
input, which has icedtea as an input -- meaning an install of the
Emacs package comes with a whole Java runtime.
For another example, emacs-emacsql is most often used to access a
SQLite database, but supports MySQL and PostgreSQL as well. The
Guix package has mariadb and postgresql in its inputs, so it can
set their program paths. As a consequence, those packages (which
I don’t use otherwise) are consuming 800mb:
$ du -shc $(find /gnu/store -maxdepth 1 -type d -name
\*-postgresql-\* -or -name \*mariadb\*) | tail -1
804Mtotal
I’m not picking on any individual package or contributor here --
as I said, the pattern is widespread -- and I have multiple
generations in the store, which increase those numbers. But this
feels like an area that could be improved.
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?
I’d love to hear others’ thoughts.
Thanks,
-- Ian
