| Message ID | bee27d4455c579e5762f3d8df8474c8cd1f20820.1620221003.git.public@yoctocell.xyz |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#48237] gnu: emacs-consult: Add ‘emacs-ve | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
| cbaines/issue | success | View issue |
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
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.
Ping! Maxim, any opinions?
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
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?
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
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?
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
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
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
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
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’?
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