emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interoperation between package managers


From: Radon Rosborough
Subject: Re: Interoperation between package managers
Date: Sat, 12 Aug 2017 10:54:00 -0700

> You have to clone&manage manually.
>
> >   If not currently, is such support a future development target
> >   for package.el?
>
> Hasn't been so far. Rather than integrate it into package.el, it
> could be a completely separate package that helps automate what I do
> manually.

I feel like I should point out that this support is exactly what is
already provided by straight.el. Not that there is anything wrong with
adding it to package.el as well, but you might find a reduced market
for it since straight.el provides better support for this use case
(because it makes this use case the *only* use case, unlike package.el
which also supports installation of tarballs from an ELPA server).

> Currently, the main way package.el was adjusted to help support the
> "elpa.git checkout in package-directory-list" was to make it so that
> packages in ~/.emacs.d/elpa don't have to use a subdirectory named
> <pkg>-<vers> but it can be named just <pkg> (otherwise we'd need to
> rename all those dirs after "git pull" to reflect the new version
> numbers).

This is fantastic! Those version numbers always annoyed me to no end
and were in fact one of the major reasons I didn't like package.el.
Glad to know they are now optional. As far as I can tell, this fact
remains completely undocumented?

Honestly, setting aside my philosophical differences with package.el,
I think the biggest problem is the documentation. User education about
`package-initialize' and stuff like that would be much less of a
problem if the documentation were clear, obvious, and concise.

(This means that elpa.gnu.org should *NOT* link to the "Package
Installation" wall-of-text from the Elisp manual and the plain-text,
developer-oriented README from the Git repo, without also providing
some more comprehensible sources of information.)

> As mentioned above, I haven't thought about what package.el could do
> to make it easier to automate what I do manually, so if you have
> suggestions for things that we could change in (or add to)
> package.el to make it easier for Borg to interoperate with it,
> please send them along,

You should talk to Jonas (cc'd) about this as he's the author of Borg.
I can't really provide much useful help beyond this point since I have
no desire to use package.el for anything.

Best,
Radon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]