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

Previous Next

Package: guix-patches;

Reported by: Xinglu Chen <public <at> yoctocell.xyz>

Date: Wed, 5 May 2021 13:27:02 UTC

Severity: normal

Tags: moreinfo, patch

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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: [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’?




This bug report was last modified 91 days ago.

Previous Next


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