GNU bug report logs - #48237
[PATCH] gnu: emacs-consult: Add ‘emacs-ve

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48237 in the body.
You can then email your comments to 48237 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Xinglu Chen <public <at> yoctocell.xyz>
To: guix-patches <at> gnu.org
Subject: [PATCH] gnu: emacs-consult: Add ‘emacs-ve
Date: Wed, 05 May 2021 15:26:12 +0200

* gnu/packages/emacs-xyz.scm (emacs-consult)[propagated-inputs]: Add
emacs-vertico.
---
emacs-vertico is an optional dependency so maybe there is a better way
deal with this.  Splitting the package into multiple outputs might be a
better idea, but I don’t know how we would do that.

 gnu/packages/emacs-xyz.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 1a640a53f3..92b3e6ce37 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -7579,7 +7579,8 @@ style, or as multiple word prefixes.")
     (build-system emacs-build-system)
     (propagated-inputs
      `(("emacs-flycheck" ,emacs-flycheck)
-       ("emacs-selectrum" ,emacs-selectrum)))
+       ("emacs-selectrum" ,emacs-selectrum)
+       ("emacs-vertico" ,emacs-vertico)))
     (home-page "https://github.com/minad/consult")
     (synopsis "Consulting completing-read")
     (description "This package provides various handy commands based on the

base-commit: 56e4d7204b0d4f83ab8cf4aab24199a9f8dc082c
-- 
2.31.1

Message #8 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: Xinglu Chen <public <at> yoctocell.xyz>, 48237 <at> debbugs.gnu.org
Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: [PATCH] gnu: emacs-consult: Add ‘emacs-ve
Date: Wed, 05 May 2021 19:39:58 +0200

Am Mittwoch, den 05.05.2021, 15:26 +0200 schrieb Xinglu Chen:
> emacs-vertico is an optional dependency so maybe there is a better
> way
> deal with this.  Splitting the package into multiple outputs might be
> a
> better idea, but I don’t know how we would do that.
This is certainly an interesting question.  With other Emacs packages,
there is sometimes a contrib version, that adds "more", see e.g. org-
mode or telega.  But those are tied closely to what upstream considers
contrib, so I don't think that applies here.

IIUC selectrum is likewise optional.  Perhaps we should consider not
propagating optional inputs, but rather adding them as normal inputs –
so that byte compilation succeeds, but users won't be forced to have a
rather large elisp library as part of their profiles if it's not
needed.

I've CC'd Maxim to get their input on the matter, the patch otherwise
LGTM.

Regards,
Leo

Message #11 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Xinglu Chen <public <at> yoctocell.xyz>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>, 48237 <at> debbugs.gnu.org
Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Fri, 07 May 2021 16:23:46 +0200

On Wed, May 05 2021, Leo Prikler wrote:

> Am Mittwoch, den 05.05.2021, 15:26 +0200 schrieb Xinglu Chen:
>> emacs-vertico is an optional dependency so maybe there is a better
>> way
>> deal with this.  Splitting the package into multiple outputs might be
>> a
>> better idea, but I don’t know how we would do that.
> This is certainly an interesting question.  With other Emacs packages,
> there is sometimes a contrib version, that adds "more", see e.g. org-
> mode or telega.  But those are tied closely to what upstream considers
> contrib, so I don't think that applies here.

Yeah, Org has a separate contrib/ directory.

> IIUC selectrum is likewise optional.  Perhaps we should consider not
> propagating optional inputs, but rather adding them as normal inputs –
> so that byte compilation succeeds, but users won't be forced to have a
> rather large elisp library as part of their profiles if it's not
> needed.

I think this might be the best option.

Message #14 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Xinglu Chen <public <at> yoctocell.xyz>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>, 48237 <at> debbugs.gnu.org
Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Wed, 02 Jun 2021 17:32:16 +0200

[Message part 1 (text/plain, inline)]

Ping!  Maxim, any opinions?

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Arun Isaac <arunisaac <at> systemreboot.net>
To: Xinglu Chen <public <at> yoctocell.xyz>, Leo Prikler
 <leo.prikler <at> student.tugraz.at>, 48237 <at> debbugs.gnu.org
Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Wed, 11 Aug 2021 20:53:28 +0530

[Message part 1 (text/plain, inline)]

Hi all,

I actually think we should not add emacs-vertico to the
propagated-inputs, and remove emacs-flycheck and emacs-selectrum as
well. All these are optional dependencies, and we should leave it to the
user to install the ones they want. At least in this specific case, the
three packages (flycheck, selectrum and vertico) are the kind the user
would want to explicitly install. They aren't backend libraries that
ought to remain invisible to the user.

In fact, this is the version of emacs-consult I have installed in my
profile.

--8<---------------cut here---------------start------------->8---
(package
  (inherit emacs-consult)
  (propagated-inputs `()))
--8<---------------cut here---------------end--------------->8---

Also, byte compilation works for me without any propagated inputs. Am I
missing something?

Regards,
Arun

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Xinglu Chen <public <at> yoctocell.xyz>
To: Arun Isaac <arunisaac <at> systemreboot.net>, Leo Prikler
 <leo.prikler <at> student.tugraz.at>, 48237 <at> debbugs.gnu.org
Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Mon, 06 Sep 2021 15:47:54 +0200

[Message part 1 (text/plain, inline)]

On Wed, Aug 11 2021, Arun Isaac wrote:

> Hi all,
>
> I actually think we should not add emacs-vertico to the
> propagated-inputs, and remove emacs-flycheck and emacs-selectrum as
> well. All these are optional dependencies, and we should leave it to the
> user to install the ones they want. At least in this specific case, the
> three packages (flycheck, selectrum and vertico) are the kind the user
> would want to explicitly install. They aren't backend libraries that
> ought to remain invisible to the user.
>
> In fact, this is the version of emacs-consult I have installed in my
> profile.
>
> --8<---------------cut here---------------start------------->8---
> (package
>   (inherit emacs-consult)
>   (propagated-inputs `()))
> --8<---------------cut here---------------end--------------->8---
>
> Also, byte compilation works for me without any propagated inputs. Am I
> missing something?

Another option would be to define package variants of ‘emacs-consult’,
that way we would have four packages:

* emacs-consult;
* emacs-consult-flycheck;
* emacs-consult-vertico; and
* emacs-consult.

WDYT?

[signature.asc (application/pgp-signature, inline)]

Message #23 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Xinglu Chen <public <at> yoctocell.xyz>
Cc: Arun Isaac <arunisaac <at> systemreboot.net>,
 Leo Prikler <leo.prikler <at> student.tugraz.at>, 48237 <at> debbugs.gnu.org
Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Mon, 06 Sep 2021 13:51:24 -0400

Hello Arun,

Xinglu Chen <public <at> yoctocell.xyz> writes:

> On Wed, Aug 11 2021, Arun Isaac wrote:
>
>> Hi all,
>>
>> I actually think we should not add emacs-vertico to the
>> propagated-inputs, and remove emacs-flycheck and emacs-selectrum as
>> well. All these are optional dependencies, and we should leave it to the
>> user to install the ones they want. At least in this specific case, the
>> three packages (flycheck, selectrum and vertico) are the kind the user
>> would want to explicitly install. They aren't backend libraries that
>> ought to remain invisible to the user.
>>
>> In fact, this is the version of emacs-consult I have installed in my
>> profile.

Guix packages typically come as featureful as possible unless there are
good reasons not too (to minimize the closure size, for example).  In
this case, the added optional dependencies seem to have negligible
effect on the closure size, according to `guix size`; I'd be in favor to
keep the optional dependencies specified for that reason, unless there
are other considerations that I'm missing.

> Another option would be to define package variants of ‘emacs-consult’,
> that way we would have four packages:
>
> * emacs-consult;
> * emacs-consult-flycheck;
> * emacs-consult-vertico; and
> * emacs-consult.

I would prefer not go that route (variants multiplication), especially
when the user already has a way to customize.

My 2 cents,

Maxim

Message #26 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Xinglu Chen
 <public <at> yoctocell.xyz>
Cc: Arun Isaac <arunisaac <at> systemreboot.net>, 48237 <at> debbugs.gnu.org
Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Mon, 06 Sep 2021 20:05:54 +0200

Am Montag, den 06.09.2021, 13:51 -0400 schrieb Maxim Cournoyer:
> Hello Arun,
> 
> Xinglu Chen <public <at> yoctocell.xyz> writes:
> 
> > On Wed, Aug 11 2021, Arun Isaac wrote:
> > 
> > > Hi all,
> > > 
> > > I actually think we should not add emacs-vertico to the
> > > propagated-inputs, and remove emacs-flycheck and emacs-selectrum
> > > as well. All these are optional dependencies, and we should leave
> > > it to the user to install the ones they want. At least in this
> > > specific case, the three packages (flycheck, selectrum and
> > > vertico) are the kind the user would want to explicitly install.
> > > They aren't backend libraries that ought to remain invisible to
> > > the user.
> > > 
> > > In fact, this is the version of emacs-consult I have installed in
> > > my profile.
> 
> Guix packages typically come as featureful as possible unless there
> are good reasons not too (to minimize the closure size, for
> example).  In this case, the added optional dependencies seem to have
> negligible effect on the closure size, according to `guix size`; I'd
> be in favor to keep the optional dependencies specified for that
> reason, unless there are other considerations that I'm missing.
While closure size is normally a good metric, with interpreted
languages like Emacs Lisp you have the added baggage of *propagating*
inputs, thereby installing stuff at user (or system) level, that the
user did not actually ask for.  My personal take on those is to provide
them as inputs where necessary to compile, but not actually propagate
them where not necessary to run.

For example, an Emacs package might require emacs-dash to function at
all and might install some autocompletion stuff with emacs-autocomplete 
or emacs-company (perhaps even both).  emacs-dash absolutely must be
propagated, but unless you're already using autocomplete or company and
thus have them in your manifest, you probably don't want them to be
installed by emacs-foo.  Does this make sense?

Message #29 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Arun Isaac <arunisaac <at> systemreboot.net>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>, Maxim Cournoyer
 <maxim.cournoyer <at> gmail.com>, Xinglu Chen <public <at> yoctocell.xyz>
Cc: 48237 <at> debbugs.gnu.org
Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Tue, 07 Sep 2021 02:04:22 +0530

[Message part 1 (text/plain, inline)]

Hi all,

> unless you're already using autocomplete or company and
> thus have them in your manifest, you probably don't want them to be
> installed by emacs-foo.  Does this make sense?

I agree. Closure size isn't the right metric for this
case. emacs-vertico and emacs-selectrum aren't really optional
dependencies in the normal sense. The user would only want one of them
in their profile, and never both. Propagating both would rather be a
nuisance to the user.

> I would prefer not go that route (variants multiplication), especially
> when the user already has a way to customize.

I agree. Variant multiplication would result in a minor combinatorial
explosion. emacs-vertico and emacs-selectrum are anyway the kind of
package a user would explicitly install in their profile.

Cheers!
Arun

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: Arun Isaac <arunisaac <at> systemreboot.net>, 48237 <at> debbugs.gnu.org,
 Xinglu Chen <public <at> yoctocell.xyz>
Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Mon, 06 Sep 2021 19:17:59 -0400

Hello,

Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:

> Am Montag, den 06.09.2021, 13:51 -0400 schrieb Maxim Cournoyer:
>> Hello Arun,
>> 
>> Xinglu Chen <public <at> yoctocell.xyz> writes:
>> 
>> > On Wed, Aug 11 2021, Arun Isaac wrote:
>> > 
>> > > Hi all,
>> > > 
>> > > I actually think we should not add emacs-vertico to the
>> > > propagated-inputs, and remove emacs-flycheck and emacs-selectrum
>> > > as well. All these are optional dependencies, and we should leave
>> > > it to the user to install the ones they want. At least in this
>> > > specific case, the three packages (flycheck, selectrum and
>> > > vertico) are the kind the user would want to explicitly install.
>> > > They aren't backend libraries that ought to remain invisible to
>> > > the user.
>> > > 
>> > > In fact, this is the version of emacs-consult I have installed in
>> > > my profile.
>> 
>> Guix packages typically come as featureful as possible unless there
>> are good reasons not too (to minimize the closure size, for
>> example).  In this case, the added optional dependencies seem to have
>> negligible effect on the closure size, according to `guix size`; I'd
>> be in favor to keep the optional dependencies specified for that
>> reason, unless there are other considerations that I'm missing.
> While closure size is normally a good metric, with interpreted
> languages like Emacs Lisp you have the added baggage of *propagating*
> inputs, thereby installing stuff at user (or system) level, that the
> user did not actually ask for.  My personal take on those is to provide
> them as inputs where necessary to compile, but not actually propagate
> them where not necessary to run.

Thanks for explaining.  It makes sense, although there would probably be
exceptions.  I'm thinking for example about emacs-elpy, for which not
propagating optional dependencies would render the package nearly
useless out of the box.

> For example, an Emacs package might require emacs-dash to function at
> all and might install some autocompletion stuff with
> emacs-autocomplete or emacs-company (perhaps even both).  emacs-dash
> absolutely must be propagated, but unless you're already using
> autocomplete or company and thus have them in your manifest, you
> probably don't want them to be installed by emacs-foo.  Does this make
> sense?

From a purity sense, yes, but propagating autocomplete or company
wouldn't cause any problems in practice, no?

As another possible option to explore to avoid propagation could be to
develop a runpath equivalent for the Emacs compiled format (.elc).  More
work, but more definitive!

Thank you,

Maxim

Message #35 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Arun Isaac <arunisaac <at> systemreboot.net>
Cc: 48237 <at> debbugs.gnu.org, Xinglu Chen <public <at> yoctocell.xyz>,
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Mon, 06 Sep 2021 19:18:47 -0400

Hello,

Arun Isaac <arunisaac <at> systemreboot.net> writes:

> Hi all,
>
>> unless you're already using autocomplete or company and
>> thus have them in your manifest, you probably don't want them to be
>> installed by emacs-foo.  Does this make sense?
>
> I agree. Closure size isn't the right metric for this
> case. emacs-vertico and emacs-selectrum aren't really optional
> dependencies in the normal sense. The user would only want one of them
> in their profile, and never both. Propagating both would rather be a
> nuisance to the user.

I see!  Thank you for explaining!

Maxim

Message #38 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Arun Isaac <arunisaac <at> systemreboot.net>, 48237 <at> debbugs.gnu.org,
 Xinglu Chen <public <at> yoctocell.xyz>
Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Tue, 07 Sep 2021 09:05:09 +0200

Hi,

Am Montag, den 06.09.2021, 19:17 -0400 schrieb Maxim Cournoyer:
> [...]
> 
> Thanks for explaining.  It makes sense, although there would probably
> be exceptions.  I'm thinking for example about emacs-elpy, for which
> not propagating optional dependencies would render the package nearly
> useless out of the box.
True, that's why those have to be evaluated on a case-by-case basis. 
FWIW, I do think that not propagating auto-completion frameworks by
more or less unrelated packages is a good rule of thumb, however.

> > For example, an Emacs package might require emacs-dash to function
> > at all and might install some autocompletion stuff with emacs-
> > autocomplete or emacs-company (perhaps even both).  emacs-dash
> > absolutely must be propagated, but unless you're already using
> > autocomplete or company and thus have them in your manifest, you
> > probably don't want them to be installed by emacs-foo.  Does this
> > make sense?
> 
> From a purity sense, yes, but propagating autocomplete or company
> wouldn't cause any problems in practice, no?
Packages installed by Guix do contribute to startup times (guix-emacs
autoloads etc.) and if you don't care about a given feature you might
also want to update one package separately from the others (because the
spacebar heater got deactivated), which would lead to a conflict of
propagated inputs.  I'm not sure how well the latter would work in
practice, but it's a thing to think about especially with libraries
that would otherwise propagate nothing.

> As another possible option to explore to avoid propagation could be
> to develop a runpath equivalent for the Emacs compiled format
> (.elc).  More work, but more definitive!
I think the bigger problem in Emacs is the lacking module system.  Even
if you have runpaths, you're still polluting the same global namespace.

Thanks

Message #41 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Xinglu Chen <public <at> yoctocell.xyz>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>, Maxim Cournoyer
 <maxim.cournoyer <at> gmail.com>
Cc: Arun Isaac <arunisaac <at> systemreboot.net>, 48237 <at> debbugs.gnu.org
Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Tue, 07 Sep 2021 19:49:07 +0200

[Message part 1 (text/plain, inline)]

On Mon, Sep 06 2021, Liliana Marie Prikler wrote:

> Am Montag, den 06.09.2021, 13:51 -0400 schrieb Maxim Cournoyer:
>> Hello Arun,
>> 
>> Xinglu Chen <public <at> yoctocell.xyz> writes:
>> 
>> > On Wed, Aug 11 2021, Arun Isaac wrote:
>> > 
>> > > Hi all,
>> > > 
>> > > I actually think we should not add emacs-vertico to the
>> > > propagated-inputs, and remove emacs-flycheck and emacs-selectrum
>> > > as well. All these are optional dependencies, and we should leave
>> > > it to the user to install the ones they want. At least in this
>> > > specific case, the three packages (flycheck, selectrum and
>> > > vertico) are the kind the user would want to explicitly install.
>> > > They aren't backend libraries that ought to remain invisible to
>> > > the user.
>> > > 
>> > > In fact, this is the version of emacs-consult I have installed in
>> > > my profile.
>> 
>> Guix packages typically come as featureful as possible unless there
>> are good reasons not too (to minimize the closure size, for
>> example).  In this case, the added optional dependencies seem to have
>> negligible effect on the closure size, according to `guix size`; I'd
>> be in favor to keep the optional dependencies specified for that
>> reason, unless there are other considerations that I'm missing.
> While closure size is normally a good metric, with interpreted
> languages like Emacs Lisp you have the added baggage of *propagating*
> inputs, thereby installing stuff at user (or system) level, that the
> user did not actually ask for.  My personal take on those is to provide
> them as inputs where necessary to compile, but not actually propagate
> them where not necessary to run.
>
> For example, an Emacs package might require emacs-dash to function at
> all and might install some autocompletion stuff with emacs-autocomplete 
> or emacs-company (perhaps even both).  emacs-dash absolutely must be
> propagated, but unless you're already using autocomplete or company and
> thus have them in your manifest, you probably don't want them to be
> installed by emacs-foo.  Does this make sense?

I just noticed that the “16.4.6 Emacs Packages” section of the manual
has the following paragraph.

     The Elisp dependencies of Emacs packages are typically provided as
  ‘propagated-inputs’ when required at run time.  As for other packages,
  build or test dependencies should be specified as ‘native-inputs’.
  
Since these optional dependencies (‘emacs-autocomplete’ and
‘emacs-company’ in your case) are not needed at runtime, would it make
sense to make them ‘native-inputs’ instead of ‘inputs’?

[signature.asc (application/pgp-signature, inline)]

Message #44 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Olivier Rojon <o.rojon <at> posteo.net>
To: Xinglu Chen <public <at> yoctocell.xyz>
Cc: Arun Isaac <arunisaac <at> systemreboot.net>, 48237 <at> debbugs.gnu.org,
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Sat, 15 Feb 2025 20:55:51 +0000

Xinglu Chen <public <at> yoctocell.xyz> writes:

Hello everyone,

I am trying to clean up orphaned or old issues.  I've read the discussion but I am not
sure if that which has been discussed is still of relevance about 3,5 years later.  Can
any one of you give an update and/or close the issue?

Have a good day :)
Olivier

> On Mon, Sep 06 2021, Liliana Marie Prikler wrote:
>
>> Am Montag, den 06.09.2021, 13:51 -0400 schrieb Maxim Cournoyer:
>>> Hello Arun,
>>> 
>>> Xinglu Chen <public <at> yoctocell.xyz> writes:
>>> 
>>> > On Wed, Aug 11 2021, Arun Isaac wrote:
>>> > 
>>> > > Hi all,
>>> > > 
>>> > > I actually think we should not add emacs-vertico to the
>>> > > propagated-inputs, and remove emacs-flycheck and emacs-selectrum
>>> > > as well. All these are optional dependencies, and we should leave
>>> > > it to the user to install the ones they want. At least in this
>>> > > specific case, the three packages (flycheck, selectrum and
>>> > > vertico) are the kind the user would want to explicitly install.
>>> > > They aren't backend libraries that ought to remain invisible to
>>> > > the user.
>>> > > 
>>> > > In fact, this is the version of emacs-consult I have installed in
>>> > > my profile.
>>> 
>>> Guix packages typically come as featureful as possible unless there
>>> are good reasons not too (to minimize the closure size, for
>>> example).  In this case, the added optional dependencies seem to have
>>> negligible effect on the closure size, according to `guix size`; I'd
>>> be in favor to keep the optional dependencies specified for that
>>> reason, unless there are other considerations that I'm missing.
>> While closure size is normally a good metric, with interpreted
>> languages like Emacs Lisp you have the added baggage of *propagating*
>> inputs, thereby installing stuff at user (or system) level, that the
>> user did not actually ask for.  My personal take on those is to provide
>> them as inputs where necessary to compile, but not actually propagate
>> them where not necessary to run.
>>
>> For example, an Emacs package might require emacs-dash to function at
>> all and might install some autocompletion stuff with emacs-autocomplete 
>> or emacs-company (perhaps even both).  emacs-dash absolutely must be
>> propagated, but unless you're already using autocomplete or company and
>> thus have them in your manifest, you probably don't want them to be
>> installed by emacs-foo.  Does this make sense?
>
> I just noticed that the “16.4.6 Emacs Packages” section of the manual
> has the following paragraph.
>
>      The Elisp dependencies of Emacs packages are typically provided as
>   ‘propagated-inputs’ when required at run time.  As for other packages,
>   build or test dependencies should be specified as ‘native-inputs’.
>   
> Since these optional dependencies (‘emacs-autocomplete’ and
> ‘emacs-company’ in your case) are not needed at runtime, would it make
> sense to make them ‘native-inputs’ instead of ‘inputs’?

Message #51 received at 48237-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Olivier Rojon <o.rojon <at> posteo.net>
Cc: Arun Isaac <arunisaac <at> systemreboot.net>, Xinglu Chen <public <at> yoctocell.xyz>,
 48237-done <at> debbugs.gnu.org, Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: Re: bug#48237: [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Sun, 16 Feb 2025 11:17:14 +0900

Hi,

Olivier Rojon <o.rojon <at> posteo.net> writes:

> Xinglu Chen <public <at> yoctocell.xyz> writes:
>
> Hello everyone,
>
> I am trying to clean up orphaned or old issues.  I've read the discussion but I am not
> sure if that which has been discussed is still of relevance about 3,5 years later.  Can
> any one of you give an update and/or close the issue?
>
> Have a good day :)

Thanks Olivier, keeping our list of opened issues relevant is very
valuable.

Since there was no concensus on what to do, and it was not clear the
suggested changes would have improved the status quo, I think it's fair
to close it now.

Done!

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.