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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hello,

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

> Am Montag, den 06.09.2021, 13:51 -0400 schrieb Maxim Cournoyer:
>> Hello Arun,
>> 
>> Xinglu Chen <public@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