Am Donnerstag, den 20.05.2021, 15:24 +0300 schrieb Andrew Tropin: > > > In other words, no particular thought was given to -pkg.el. It > > > was > > > simply dropped along with many other files. So, if consensus is > > > reachedthat keeping -pkg.el is a good idea, there is no reason to > > > not > > > do that. > > Thanks for clearing that up. In that case, I don't have any qualms > > about including them either. > > Cool, seems we can get -pkg.el files back. Yes, we can.
> > Multi-profile Emacs should be supported, but this also breaks on > > foreign distros with foreign distro ELPA. Again, hacking variables > > is not the solution (and even if it was, it'd be better to patch > > the emacs default value, not that this is a good idea either). > > Yep, the last snippet supports multi-profile Emacs. While that's better, I still don't think it's sufficient. > Installing packages for Emacs via a few different package manager > sounds like a very bad practice) I agree that current implementation > with updating variables isn't perfect and it doesn't cover the use > case, which I expect to be rare (packages from Guix will be listed in > list-packages, files from foreign distro PM won't). I can dive into > package.el implementation and spend some time next week providing a > different workaround. I think this is common practice on other distros. For example your system provides auctex, but it doesn't provide dash.el. What do you do? Install it through ELPA. Now let's say, you have Guix installed. Guix provides packages for some of ELPA, but not what you want. You could hack together a Guix package based on the ELPA importer, but perhaps upstream is slow in accepting it or perhaps you've fetched the package from a shady source, that Guix won't accept. So you have foreign distro system packages + Guix + personal ELPA. As far as getting Guix packages to work without affecting the rest of package.el or user configuration, I think an advice, that runs after package-load-all-descriptors might be necessary. As for the candidates to check for this advice, you can read all subdirs.el files you find inside load-path. When they're formatted (normal-top-level-add-to-load-path (list P1 ... PN)) they were likely added by Guix (even if not, one should probably consider them important) and P1 ... PN should be scanned for descriptors. > BTW, can you remind me why we do not place packages under > site-lisp/elpa/NAME-VERSION? It seems almost the same as > site-lisp/NAME-VERSION, but everything related to describe-package > and other functions will work out of the box. This way it will work > even with a foreign distro use case. Again, Guix is not ELPA and calling it ELPA would be misleading. As for why we don't put stuff in any other site-lisp/ directory, e.g. site-lisp/guix.d/NAME-VERSION, doing that led to rather tricky issues, which is why we've decided to use site-lisp "directly". The current way of handling things is a bit of a compromise. It gives you per- package directories like ELPA, but unlike ELPA can easily be handled at Emacs startup.
