From: Xinglu Chen <public@yoctocell.xyz>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>,
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: Arun Isaac <arunisaac@systemreboot.net>, 48237@debbugs.gnu.org
Subject: [bug#48237] [PATCH] gnu: emacs-consult: Add ‘emacs-ve
Date: Tue, 07 Sep 2021 19:49:07 +0200 [thread overview]
Message-ID: <87zgsoz370.fsf@yoctocell.xyz> (raw)
In-Reply-To: <fd28931b2c8a997621958bed77802cc9ef24822c.camel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]
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@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’?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
prev parent reply other threads:[~2021-09-07 17:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-05 13:26 [bug#48237] [PATCH] gnu: emacs-consult: Add ‘emacs-ve Xinglu Chen
2021-05-05 17:39 ` Leo Prikler
2021-05-07 14:23 ` Xinglu Chen
2021-06-02 15:32 ` Xinglu Chen
2021-08-11 15:23 ` Arun Isaac
2021-09-06 13:47 ` Xinglu Chen
2021-09-06 17:51 ` Maxim Cournoyer
2021-09-06 18:05 ` Liliana Marie Prikler
2021-09-06 20:34 ` Arun Isaac
2021-09-06 23:18 ` Maxim Cournoyer
2021-09-06 23:17 ` Maxim Cournoyer
2021-09-07 7:05 ` Liliana Marie Prikler
2021-09-07 17:49 ` Xinglu Chen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zgsoz370.fsf@yoctocell.xyz \
--to=public@yoctocell.xyz \
--cc=48237@debbugs.gnu.org \
--cc=arunisaac@systemreboot.net \
--cc=liliana.prikler@gmail.com \
--cc=maxim.cournoyer@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).