unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
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 --]

      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).