| Message ID | CABrWRW2F8x4f8WD2d+N8w9i7hNJTRPH_k26ZnELb_W_WRMR_Uw@mail.gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#44555] gnu: Add emacs-next-use-package | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/applying patch | fail | View Laminar job |
Dear, On Tue, 10 Nov 2020 at 17:13, Andrew Tropin <andrew@trop.in> wrote: > +(define-public emacs-next-use-package > + (let ((commit "4fb1f9a68f1e7e7d614652afc017a6652fd029f1") > + (revision "20200721")) > + (package/inherit emacs-use-package > + (name "emacs-next-use-package") > + (version (git-version "2.4" revision commit)) > + (source > + (origin > + (method git-fetch) > + (uri (git-reference > + (url "https://github.com/jwiegley/use-package") > + (commit commit))) > + (file-name (git-file-name name version)) > + (sha256 > + (base32 > + "073sm0mbxcjysap2bjzf1cl0134jy8a0xig7ywmmd0bm2y8qzfip")))) > + (propagated-inputs '())))) > + Maybe I am missing something, but it is not built using 'emacs-next'. Why not simply update the package 'emacs-use-package' with a comment explaining what you already explained? All the best, simon
> Maybe I am missing something, but it is not built using 'emacs-next'. > Why not simply update the package 'emacs-use-package' with a comment > explaining what you already explained? It's true, it's built with emacs-minimal and probably the name is a little confusing in that sense. The original idea was to just update current emacs-use-package, but during discussion in #guix leoprikler mentioned that emacs-use-package works fine for users of Emacs 27 and because the revision I picked is not a stable tag, but just a fresh commit of use-package and I do it to make people able to use it from Emacs 28 it would be logical to create a separate package and keep stable 2.4 version for other users. Also, removing diminish from propagated inputs can break someone's setup. My original patch was: http://ix.io/2DDt I think it should be safe to just update emacs-use-package to the more recent revision. It will work for both 27 and 28 users. Let me know what you think and what you advise to do next.
Hello zimoun, it was me, who suggested (in IRC) to keep two different packages, as it appeared to me to be a non-trivial transaction (given the changes to propagated-inputs) with the intent to make things run on Emacs 28. I did try to point out, that it can/should be built with Emacs 28, but there appears to have been some miscommunication. Regards, Leo
zimoun <zimon.toutoune@gmail.com> writes: > Maybe I am missing something, but it is not built using 'emacs-next'. > Why not simply update the package 'emacs-use-package' with a comment > explaining what you already explained? If this package doesn't work with emacs28 as it is, I also think it is good/ok to bump it to a non release commit. But why also remove propagated-inputs (diminish)? I use diminish with emacs28 w/o trouble. diminish is a very small and clean package/sources (and very funny to read, *love it*). Maybe we need to debug this better/harder to find the (real) issue? Andrew, do you have any error message/debug output for the combination use-package/diminish with emacs28?
> But why also remove propagated-inputs (diminish)? > I use diminish with emacs28 w/o trouble. > diminish is a very small and clean package/sources (and very funny to > read, *love it*). There is no issue with diminish itself. I just don't know why it is specified as propagated-input. It's an optional dependency as well as delight, key-chord and many other use-package extensions and it should be installed explicitly by the user, not pulled as a dependency. Probably I had to do it with another patch to make it clearer.
Andrew Tropin <andrew@trop.in> writes: > There is no issue with diminish itself. I just don't know why it > is specified as propagated-input. It's an optional dependency as > well as delight, key-chord and many other use-package extensions > and it should be installed explicitly by the user, not pulled as a > dependency. > > Probably I had to do it with another patch to make it clearer. Normally, we try to install optional packages per default. Sometimes, it's not so easy and one has to weigh up... Maybe the use-case for use-package is so that diminish is very often needed? Or for too many users, it would be "useless" (or break something), w/o it? Imho (I don't have commit superpower), you need a reason to remove an input (and here, this means provided/out of the box experience). Or at least make a comment in the source _why_ it isn't needed etc...
Dear, On Tue, 10 Nov 2020 at 19:00, Leo Prikler <leo.prikler@student.tugraz.at> wrote: > it was me, who suggested (in IRC) to keep two different packages, as it > appeared to me to be a non-trivial transaction (given the changes to > propagated-inputs) with the intent to make things run on Emacs 28. I > did try to point out, that it can/should be built with Emacs 28, but > there appears to have been some miscommunication. Thank you both for the explanations. Well, the fix has finally been from upstream, if I read correctly. :-) However, Guix is still missing a good story to build the Emacs packages using ’emacs-minimal’ or ’emacs-next’ or any other elisp bytecode compiler (emacs-guile, REmacs, emacs-gccjit, etc.). All the best, simon
diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm index ff546506e9..3fe14a210a 100644 --- a/gnu/packages/emacs-xyz.scm +++ b/gnu/packages/emacs-xyz.scm @@ -11172,6 +11172,24 @@ configuration in your @file{.emacs} file in a way that is both performance-oriented and tidy.") (license license:gpl2+))) +(define-public emacs-next-use-package + (let ((commit "4fb1f9a68f1e7e7d614652afc017a6652fd029f1") + (revision "20200721")) + (package/inherit emacs-use-package + (name "emacs-next-use-package") + (version (git-version "2.4" revision commit)) + (source + (origin + (method git-fetch) + (uri (git-reference + (url "https://github.com/jwiegley/use-package") + (commit commit))) + (file-name (git-file-name name version)) + (sha256 + (base32 + "073sm0mbxcjysap2bjzf1cl0134jy8a0xig7ywmmd0bm2y8qzfip")))) + (propagated-inputs '())))) + (define-public emacs-leaf (package
use-package version 2.4 doesn't work with emacs-next (28), but there is no other new tags in upstream repository. The last one is 2.4 and it was created in Nov 2018. Other GNU/Linux distros uses more recent, but untagged revision. This commit does the same. Additionally, it removes diminish from propagated-inputs because this dependency is optional. The only required dependencies are emacs and bind-key. --- gnu/packages/emacs-xyz.scm | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (name "emacs-leaf")