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

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

[Xinglu Chen]

* 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(-)

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

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

[Leo Prikler]

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.

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

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

[Xinglu Chen]

On Wed, May 05 2021, Leo Prikler wrote:

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

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

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

[Xinglu Chen]

[-- Attachment #1: Type: text/plain, Size: 29 bytes --]


Ping!  Maxim, any opinions?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

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

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]


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?

Regards,
Arun

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 524 bytes --]

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

[Xinglu Chen]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

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

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

> 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

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

[Liliana Marie Prikler]

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?

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

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 524 bytes --]

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

[Maxim Cournoyer]

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

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

[Maxim Cournoyer]

Hello,

Arun Isaac <arunisaac@systemreboot.net> writes:

> 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

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

[Liliana Marie Prikler]

Hi,

Am Montag, den 06.09.2021, 19:17 -0400 schrieb Maxim Cournoyer:
> [...]
> 
> 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.

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

> 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

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

[Xinglu Chen]

[-- 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 --]