all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Radon Rosborough <radon.neon@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Jonas Bernoulli <jonas@bernoul.li>, emacs-devel@gnu.org
Subject: Re: Interoperation between package managers
Date: Sat, 12 Aug 2017 10:54:00 -0700	[thread overview]
Message-ID: <CADB4rJE-urpOCXOvRGxYqmGShkTQQzh-DZgY8roXhM94ixTReA@mail.gmail.com> (raw)
In-Reply-To: <jwvfucxrd9k.fsf-monnier+gmane.emacs.devel@gnu.org>

> 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	other threads:[~2017-08-12 17:54 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-07  0:37 Friendly discussion about (package-initialize) Radon Rosborough
2017-08-07  1:39 ` Stefan Monnier
2017-08-07  2:16   ` Radon Rosborough
2017-08-07  2:44     ` Stefan Monnier
2017-08-07  4:12       ` Radon Rosborough
2017-08-09 20:24         ` Stefan Monnier
2017-08-10  3:32           ` Radon Rosborough
2017-08-10  4:25             ` Eli Zaretskii
2017-08-10  4:39               ` Radon Rosborough
2017-08-10  7:24                 ` Eli Zaretskii
2017-08-10 17:06                   ` Radon Rosborough
2017-08-10 19:08                     ` Eli Zaretskii
2017-08-10 19:31                       ` Radon Rosborough
2017-08-10 20:00                       ` Mark Oteiza
2017-08-11  6:14                         ` Eli Zaretskii
2017-08-11  1:25                     ` Nick Helm
2017-08-11 21:43                       ` Stefan Monnier
2017-08-09 20:35         ` Interoperation between package managers (was: Friendly discussion about (package-initialize)) Stefan Monnier
2017-08-10  3:54           ` Radon Rosborough
2017-08-10 21:34             ` Interoperation between package managers Stefan Monnier
2017-08-11  2:14               ` Radon Rosborough
2017-08-11 22:05                 ` Stefan Monnier
2017-08-12 17:54                   ` Radon Rosborough [this message]
2017-08-12 20:53                     ` Jonas Bernoulli
2017-08-13 21:43                       ` Stefan Monnier
2017-08-13 21:25                     ` Stefan Monnier
2017-08-13 22:42                       ` Radon Rosborough
2017-08-13 23:32                         ` Stefan Monnier
2017-08-14  0:29                           ` Radon Rosborough
2017-08-14  8:02                             ` Stefan Monnier
2017-08-23 19:39             ` Nikolay Kudryavtsev
2017-08-23 20:58               ` Radon Rosborough
2017-08-24 12:36                 ` Nikolay Kudryavtsev
2017-08-24 20:11                   ` Radon Rosborough
2017-08-25 14:31                     ` Nikolay Kudryavtsev
2017-08-24 15:04               ` Ted Zlatanov
2017-08-24 15:46                 ` Nikolay Kudryavtsev
2017-08-07  3:20   ` Friendly discussion about (package-initialize) Noam Postavsky
2017-08-07  4:14   ` Mark Oteiza
2017-08-08  0:47     ` Stefan Monnier
2017-08-10 20:15       ` Mark Oteiza
2017-08-10 21:29         ` Stefan Monnier
2017-08-11  1:14           ` Mark Oteiza
2017-08-11  8:03             ` Clément Pit-Claudel
2017-08-07  6:52 ` Colin Baxter

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=CADB4rJE-urpOCXOvRGxYqmGShkTQQzh-DZgY8roXhM94ixTReA@mail.gmail.com \
    --to=radon.neon@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=jonas@bernoul.li \
    --cc=monnier@iro.umontreal.ca \
    /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/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.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.