unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
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: Tue, 11 May 2021 21:57:02 +0200	[thread overview]
Message-ID: <6cba9730ace19ecebc397023b243cdb02486cc0c.camel@student.tugraz.at> (raw)
In-Reply-To: <CABrWRW1WfF0J=Pe1E-R2fyx7f6+qLPMs9nj5C2_ZS-G2SZ5bGQ@mail.gmail.com>

Am Dienstag, den 11.05.2021, 21:55 +0300 schrieb Andrew Tropin:
> > the "-pkg\\.el$" exclude might have existed for a reason
> > (I don't know which, put perhaps byte compilation).
> 
> Perhaps it should be ignored during byte compilation, but still
> installing it seems to be a good idea.  Ok, let's wait for Maxim
> answer.
I think we agree on that.

> > I know people take package.el for granted nowadays, but alternative
> > package managers for Emacs have their uses.  This is not just a
> > Guix thing :)
> 
> Why not take it for granted?)  It's built-in since 24(?), elpa/melpa
> archives respect it format and provide package descriptions in
> -pkg.el format, AFAIK.  
el-get[1] is still active.
straight.el[2] is another package manager for Emacs, its README
comparing 5+1 approaches for package mangers, including el-get and
package.el.  Those are very much wild lands, I say.

Not to speak for all the distro-specific ways of handling things. 
Gentoo had (and probably still has) an overlay, that magically creates
Gentoo packages from elpa – in which of course they drop the -pkg.el. 
Debian has a mix of elpa packages and non-elpa ones, some of which
naturally don't have the -pkg.el either.  (Also their packages use
site-lisp/elpa-src instead of site-lisp/elpa).  Arch also seems to
install at least some Elisp packages "directly" in site-lisp/$PACKAGE.

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

> Don't see too many reasons not to follow this format.
> 
> I mean it's easily fixable with current directory structure just by
> stripping "/elpa" suffix from package-directory-list, but why we
> would do that emacs "customization" instead of just placing packages
> under /elpa subdirectory and make everything work out of the box?
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.

> > I don't think we want to fake elpa that hard.  Two iterations ago
> > it was .guix.d and people didn't really like it.
> 
> Do you mean the package installation path was site-lisp/.guix.d/NAME-
> VERSION?
Yep, that was a kinda ELPA-y convention while also remaining more true
to what we're doing.

> > My subdirs.el patch is also stretching it.
> 
> Not sure what you mean by this, sorry, I'm not native speaker and
> automated translation doesn't make sense to me.  Rephrase please.
The patch, which I've made, that adds subdirs.el is not
uncontroversial.

> I do not insist on any particular directory structure, just curious
> why not to stick to the widely adopted format.  Once again, thank you
> for placing packages into subdirectories, now the site-lisp structure
> seems more organized and less polluted + problem with describe-
> package (C-h P) and list-packages are easily fixable.  Appreciate
> your work!)
I hope I've shed some light as to how "wide" this adoption actually is
– Emacs users are a contentious people.  Just because something is "the
default" and enjoys being shipped with Emacs itself doesn't mean that
everyone is happy with it.

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.

Regards,
Leo

[1] https://github.com/dimitri/el-get
[2] https://github.com/raxod502/straight.el





  reply	other threads:[~2021-05-11 19:58 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 [this message]
2021-05-19 14:32           ` Andrew Tropin
2021-05-19 15:08             ` Leo Prikler
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

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6cba9730ace19ecebc397023b243cdb02486cc0c.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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).