From: Radon Rosborough <radon.neon@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Interoperation between package managers
Date: Thu, 10 Aug 2017 19:14:15 -0700 [thread overview]
Message-ID: <CADB4rJHRMa6gv9-x5KRr7tKbZzPrF2wwhqhJbxGm0AT+8MpDYw@mail.gmail.com> (raw)
In-Reply-To: <jwvvalvxgb7.fsf-monnier+gmane.emacs.devel@gnu.org>
> I don't know what you mean by "the package.el format".
I meant the one in ~/.emacs.d/elpa.
> the way I use elpa.git with package.el is:
>
> git clone .../elpa.git
> cd elpa
> make
>
> and then add that directory to package-directory-list.
> That lets me use packages directly from the local Git repository (which
> I find important in order for `C-h f` and such to directly jump to
> the real source files that I can edit, with VCS metadata).
I had no idea that package.el was capable of this. Thank you for
informing me; I will have to amend some of my published criticisms of
package.el. I have actually never seen anybody else doing this with
package.el, or indeed any mention that such a thing was possible.
Thus, I have a couple of follow-up questions:
- Is this use case documented in any way? I looked at the docstring
for `package-directory-list' and it just said that the variable is
for system-wide use only, and that you should use `package-user-dir'
for your personal packages. Notably absent was any mention of what
"directories containing Emacs Lisp packages" means, since all sorts
of different formats could be expected.
- I had originally assumed that `package-directory-list' included
packages in an ELPA-server-compatible format, and that package.el
would display these packages in `package-list-packages', and you
could install them into ~/.emacs.d/elpa (thus making copies of the
files). You are saying this is not the case, right?
- Is this the intended way to use package.el? Every tutorial I've seen
only covers installing packages from a local or remote ELPA
repository.
- When you modify a package, how is byte-compilation and autoload
generation handled? Do you just have to run 'make' again? Does that
mean you have to hope that every package's Git repository provides a
byte-compilation and autoload generation mechanism, and then
remember how to use each of them? (Here I am talking about packages
that are not in GNU ELPA, i.e. the majority of them.)
- Does package.el officially support installing packages from
version-control, or do you have to clone and manage the repositories
manually? If not currently, is such support a future development
target for package.el?
So package.el interop may indeed be useful for Borg. It will not be
useful for straight.el regardless, since straight.el makes
compatibility with package.el an explicit non-goal. But in any case, I
think the standardization you have proposed is a great idea, since it
appears that every package manager other than straight.el could
benefit from it.
Best,
Radon
next prev parent reply other threads:[~2017-08-11 2:14 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 [this message]
2017-08-11 22:05 ` Stefan Monnier
2017-08-12 17:54 ` Radon Rosborough
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=CADB4rJHRMa6gv9-x5KRr7tKbZzPrF2wwhqhJbxGm0AT+8MpDYw@mail.gmail.com \
--to=radon.neon@gmail.com \
--cc=emacs-devel@gnu.org \
--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.