[PATCH] gnu: emacs-consult: Add ‘emacs-ve

Open

Details

5 participants

Arun Isaac
Leo Prikler
Liliana Marie Prikler
Maxim Cournoyer
Xinglu Chen

Owner: unassigned

Submitted by: Xinglu Chen

Severity: normal

Xinglu Chen wrote on 5 May 2021 15:26

Recipients:(address . guix-patches@gnu.org)

Message-ID:bee27d4455c579e5762f3d8df8474c8cd1f20820.1620221003.git.public@yoctocell.xyz

* gnu/packages/emacs-xyz.scm (emacs-consult)[propagated-inputs]: Add

emacs-vertico.

---

emacs-vertico is an optional dependency so maybe there is a better way

deal with this. Splitting the package into multiple outputs might be a

better idea, but I don’t know how we would do that.

gnu/packages/emacs-xyz.scm | 3 ++-

1 file changed, 2 insertions(+), 1 deletion(-)

Toggle diff (18 lines)diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 1a640a53f3..92b3e6ce37 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -7579,7 +7579,8 @@ style, or as multiple word prefixes.")
     (build-system emacs-build-system)
     (propagated-inputs
      `(("emacs-flycheck" ,emacs-flycheck)
-       ("emacs-selectrum" ,emacs-selectrum)))
+       ("emacs-selectrum" ,emacs-selectrum)
+       ("emacs-vertico" ,emacs-vertico)))
     (home-page "https://github.com/minad/consult")
     (synopsis "Consulting completing-read")
     (description "This package provides various handy commands based on the

base-commit: 56e4d7204b0d4f83ab8cf4aab24199a9f8dc082c
-- 
2.31.1

Leo Prikler wrote on 5 May 2021 19:39

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:ae577b203f68d766d7dc8b89c3dd2ac5067c192d.camel@student.tugraz.at

Am Mittwoch, den 05.05.2021, 15:26 +0200 schrieb Xinglu Chen:

Toggle quote (5 lines)> emacs-vertico is an optional dependency so maybe there is a better
> way
> deal with this.  Splitting the package into multiple outputs might be
> a
> better idea, but I don’t know how we would do that.

This is certainly an interesting question.  With other Emacs packages,
there is sometimes a contrib version, that adds "more", see e.g. org-
mode or telega.  But those are tied closely to what upstream considers
contrib, so I don't think that applies here.

IIUC selectrum is likewise optional.  Perhaps we should consider not
propagating optional inputs, but rather adding them as normal inputs –
so that byte compilation succeeds, but users won't be forced to have a
rather large elisp library as part of their profiles if it's not
needed.

I've CC'd Maxim to get their input on the matter, the patch otherwise
LGTM.

Regards,
Leo

Xinglu Chen wrote on 7 May 2021 16:23

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

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:87k0oa4o7h.fsf@yoctocell.xyz

On Wed, May 05 2021, Leo Prikler wrote:

Toggle quote (11 lines)> Am Mittwoch, den 05.05.2021, 15:26 +0200 schrieb Xinglu Chen:
>> emacs-vertico is an optional dependency so maybe there is a better
>> way
>> deal with this.  Splitting the package into multiple outputs might be
>> a
>> better idea, but I don’t know how we would do that.
> This is certainly an interesting question.  With other Emacs packages,
> there is sometimes a contrib version, that adds "more", see e.g. org-
> mode or telega.  But those are tied closely to what upstream considers
> contrib, so I don't think that applies here.

Yeah, Org has a separate contrib/ directory.

Toggle quote (6 lines)

> IIUC selectrum is likewise optional. Perhaps we should consider not

> propagating optional inputs, but rather adding them as normal inputs –

> so that byte compilation succeeds, but users won't be forced to have a

> rather large elisp library as part of their profiles if it's not

> needed.

I think this might be the best option.

Xinglu Chen wrote on 2 Jun 2021 17:32

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:871r9kl1tr.fsf@yoctocell.xyz

Ping! Maxim, any opinions?

Arun Isaac wrote on 11 Aug 2021 17:23

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:87pmukuhsf.fsf@systemreboot.net

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.

Toggle snippet (5 lines)

(package

(inherit emacs-consult)

(propagated-inputs `()))

Also, byte compilation works for me without any propagated inputs. Am I

missing something?

Regards,

Arun

Xinglu Chen wrote on 6 Sep 2021 15:47

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:87v93d24tx.fsf@yoctocell.xyz

On Wed, Aug 11 2021, Arun Isaac wrote:

Toggle quote (22 lines)> 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.
>
> --8<---------------cut here---------------start------------->8---
> (package
>   (inherit emacs-consult)
>   (propagated-inputs `()))
> --8<---------------cut here---------------end--------------->8---
>
> Also, byte compilation works for me without any propagated inputs. Am I
> missing something?

Another option would be to define package variants of ‘emacs-consult’,

that way we would have four packages:

* emacs-consult;

* emacs-consult-flycheck;

* emacs-consult-vertico; and

* emacs-consult.

WDYT?

Maxim Cournoyer wrote on 6 Sep 2021 19:51

Recipients:(name . Xinglu Chen)(address . public@yoctocell.xyz)

Message-ID:8735qhbnj7.fsf@gmail.com

Hello Arun,

Xinglu Chen <public@yoctocell.xyz> writes:

Toggle quote (15 lines)> 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.

Toggle quote (8 lines)

> Another option would be to define package variants of ‘emacs-consult’,

> that way we would have four packages:

> * emacs-consult;

> * emacs-consult-flycheck;

> * emacs-consult-vertico; and

> * emacs-consult.

I would prefer not go that route (variants multiplication), especially

when the user already has a way to customize.

My 2 cents,

Maxim

Liliana Marie Prikler wrote on 6 Sep 2021 20:05

Recipients:

Message-ID:fd28931b2c8a997621958bed77802cc9ef24822c.camel@gmail.com

Am Montag, den 06.09.2021, 13:51 -0400 schrieb Maxim Cournoyer:

Toggle quote (26 lines)> 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?

Arun Isaac wrote on 6 Sep 2021 22:34

Recipients:(address . 48237@debbugs.gnu.org)

Message-ID:87ilzdl9yp.fsf@systemreboot.net

Hi all,

Toggle quote (4 lines)

> 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 agree. Closure size isn't the right metric for this
case. emacs-vertico and emacs-selectrum aren't really optional
dependencies in the normal sense. The user would only want one of them
in their profile, and never both. Propagating both would rather be a
nuisance to the user.

Toggle quote (3 lines)

> I would prefer not go that route (variants multiplication), especially

> when the user already has a way to customize.

I agree. Variant multiplication would result in a minor combinatorial
explosion. emacs-vertico and emacs-selectrum are anyway the kind of
package a user would explicitly install in their profile.

Cheers!
Arun

Maxim Cournoyer wrote on 7 Sep 2021 01:17

Recipients:(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)

Message-ID:87v93d8fa0.fsf@gmail.com

Hello,

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

Toggle quote (34 lines)> 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.

Toggle quote (8 lines)

> 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

Maxim Cournoyer wrote on 7 Sep 2021 01:18

Recipients:(name . Arun Isaac)(address . arunisaac@systemreboot.net)

Message-ID:87r1e18f8o.fsf@gmail.com

Hello,

Arun Isaac <arunisaac@systemreboot.net> writes:

Toggle quote (12 lines)> Hi all,
>
>> 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 agree. Closure size isn't the right metric for this
> case. emacs-vertico and emacs-selectrum aren't really optional
> dependencies in the normal sense. The user would only want one of them
> in their profile, and never both. Propagating both would rather be a
> nuisance to the user.

I see! Thank you for explaining!

Maxim

Liliana Marie Prikler wrote on 7 Sep 2021 09:05

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:73974dbbd116dd51a5c5a83f6dd37fde64a68035.camel@gmail.com

Hi,

Am Montag, den 06.09.2021, 19:17 -0400 schrieb Maxim Cournoyer:

Toggle quote (6 lines)> [...]
> 
> 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.

True, that's why those have to be evaluated on a case-by-case basis.

FWIW, I do think that not propagating auto-completion frameworks by

more or less unrelated packages is a good rule of thumb, however.

Toggle quote (10 lines)> > 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?

Packages installed by Guix do contribute to startup times (guix-emacs
autoloads etc.) and if you don't care about a given feature you might
also want to update one package separately from the others (because the
spacebar heater got deactivated), which would lead to a conflict of
propagated inputs.  I'm not sure how well the latter would work in
practice, but it's a thing to think about especially with libraries
that would otherwise propagate nothing.

Toggle quote (3 lines)

> 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!

I think the bigger problem in Emacs is the lacking module system. Even

if you have runpaths, you're still polluting the same global namespace.

Thanks

Xinglu Chen wrote on 7 Sep 2021 19:49

Recipients:

Message-ID:87zgsoz370.fsf@yoctocell.xyz

On Mon, Sep 06 2021, Liliana Marie Prikler wrote:

Toggle quote (41 lines)> 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’?

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 48237@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 48237

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date