From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Andrew Tropin <andrew@trop.in>
Cc: 48331@debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: bug#48331: Emacs' describe-package doesn't work for packages managed by guix
Date: Wed, 19 May 2021 17:08:30 +0200 [thread overview]
Message-ID: <437d90a3cc91400fdf0828fea2c989c277a73a7c.camel@student.tugraz.at> (raw)
In-Reply-To: <CABrWRW1ZYToRkrwVA5t0J3oz9X-tjF3mEyD_GfusDneV1p_9EQ@mail.gmail.com>
Am Mittwoch, den 19.05.2021, 17:32 +0300 schrieb Andrew Tropin:
> > > Most other package managers seem to respect "infrastructure"
> > > provided by package.el.
> > I don't think that statement is well-supported by the data we have.
>
> Agree, that was an incorrect statement. I should have said something
> like: there are some popular tools like use-package configuration
> helper, Nix package manager, Spacemacs configuration framework, some
> elisp archives and probably something else, which utilize and follow
> package.el. Not all of them use package.el itself, but they follow
> conventions and describe-package help command and some other work
> correctly.
Is package.el really so well supported by all these tools? I might
concede, that some of them don't throw away the package.el blurb like
guix does, but other than that, I think you'd have a hard time stuffing
a random git repo from use-package into package.el. Am I missing
something?
> > Why should we let ELPA dictate our layout? I have not even once
> > tried customizing package.el for actual use since I got Guix,
> > because the elpa importer is trivial.
>
> We don't have to. Actually, I'm very happy with the new (current)
> layout we have right now.
That's good :)
> I would say I find the following use case very confusing for
> newcomers:
> - Install emacs package via Guix.
> - Use built-in help C-h C-h, find C-h P.
> - Get it to work for built-in packages, but not for packages
> installed by Guix.
> - Get frustrated.
You mean Emacs newcomers? Tell me something new about the first-time
Emacs experience :P
> I think we could avoid this at least in two ways:
> 1. Use elpa/ subdirectory.
> 2. Keep current structure, set package-directory-list to .../site-
> lisp instead of .../site-lisp/elpa by default.
Neither sounds very pleasant, but does (2) even work?
> > Thus we're not trying to keep in line with any specific package
> > manager, we just need to make things work "with Emacs" in the sense
> > that packages installed via Guix should have working autoloads and
> > one should be able to (require ...) them.
>
> Yes, but at the same time I don't see reasons why not to implement
> one of two options above. We can get both: working autoloads and
> working built-in help function (+newcommers won't be so frustrated).
Of course. The glue code for that would go into guix-emacs.el, just
like our autoload glue.
> Personally, I'm quite happy that packages got their own
> subdirectories and I'm fully satisfied with current state of it, but
> it would be cool if inexperienced users will be able to use at least
> built-in help commands for packages out of the box without additional
> configuration.
>
> Hope my original point is a little better worded now.
Doing something in Emacs without configuration sounds like an oxymoron,
but I get your point. At the same time, I think that this kind of
change is a pretty large request (DPD has more than 100 lines not
counting dependencies, it's not small and neat like guix-emacs.el).
If you find a clever trick to make your troubles go away, do submit a
patch, but don't let it rely on user setup (in particular, don't rely
on "haha, the user always carries about the elpa subdirectory").
Regards,
Leo
next prev parent reply other threads:[~2021-05-19 15:09 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 7:51 bug#48331: Emacs' describe-package doesn't work for packages managed by guix Andrew Tropin
2021-05-11 10:05 ` Leo Prikler
2021-05-11 15:57 ` Andrew Tropin
2021-05-11 16:33 ` Leo Prikler
2021-05-11 18:55 ` Andrew Tropin
2021-05-11 19:57 ` Leo Prikler
2021-05-19 14:32 ` Andrew Tropin
2021-05-19 15:08 ` Leo Prikler [this message]
2021-05-19 17:58 ` Andrew Tropin
2021-05-19 18:42 ` Leo Prikler
2021-05-20 10:01 ` Andrew Tropin
2021-05-20 10:20 ` Leo Prikler
2021-05-20 10:32 ` Arun Isaac
2021-05-20 10:39 ` Arun Isaac
2021-05-20 11:13 ` Leo Prikler
2021-05-20 12:24 ` Andrew Tropin
2021-05-20 15:57 ` Leo Prikler
2021-05-22 3:09 ` Maxim Cournoyer
2021-12-03 20:46 ` Liliana Marie Prikler
2021-12-06 4:52 ` Andrew Tropin
2021-12-30 8:12 ` Andrew Tropin
2021-05-11 21:17 ` Ludovic Courtès
2021-05-19 14:41 ` Andrew Tropin
2021-05-22 12:54 ` bug#48331: [PATCH 1/2] build-system: emacs: Keep -pkg.el files Leo Prikler
2021-05-22 12:54 ` bug#48331: [PATCH 2/2] gnu: emacs: Load package descriptors from packages referenced by subdirs.el Leo Prikler
2021-05-25 13:40 ` bug#48331: [PATCH draft] build-system: emacs: Generate -pkg.el file in case it is missing Andrew Tropin
2021-05-25 15:07 ` Leo Prikler
2021-05-26 8:15 ` bug#48331: [PATCH] guix: build: emacs-build-system: Make package.el aware of guix packages Ivan Sokolov
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=437d90a3cc91400fdf0828fea2c989c277a73a7c.camel@student.tugraz.at \
--to=leo.prikler@student.tugraz.at \
--cc=48331@debbugs.gnu.org \
--cc=andrew@trop.in \
--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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.