Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add‘emacs-ve

From: Olivier Rojon <[email-masked]>
Date: Sat, 15 Feb 2025 20:55:51 +0000

Xinglu Chen <[email-masked]> 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 <[email-masked]> 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’?