From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Radon Rosborough <radon.neon@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Interoperation between package managers
Date: Mon, 14 Aug 2017 04:02:51 -0400 [thread overview]
Message-ID: <jwvpobymw2l.fsf-monnier+Inbox@gnu.org> (raw)
In-Reply-To: <CADB4rJH+wyGxUzdo5bSuh18OPVv+sUfKDE0EqkBZCq_othm_+Q@mail.gmail.com> (Radon Rosborough's message of "Sun, 13 Aug 2017 17:29:15 -0700")
> The current manual [1] implies that it is the responsibility of the
> upstream package maintainer to create a <pkg>-pkg.el file when
> packaging their package. If that wasn't the intention, the
> documentation should make this clear. But at this point, I would
> advise against trying to enforce a new convention, given how useful it
> is to have a consistent one established.
Using a new, fixed name which doesn't include the package's name is an
incompatible change in itself anyway, so it can break various other
aspects of compatibility at the same time.
>> I was thinking about it in the context of packages which can come
>> from the user's config as well as from the system (i.e. installed by
>> the sysadmin).
> In this case, wouldn't the multiple versions be installed in entirely
> different directories anyway?
Yes.
>> There are other cases where it can make sense. E.g. have both
>> foo-1.0 and foo-2.0 installed at the same time, because foo-2.0
>> requires Emacs-25 and you use both Emacs-25 and Emacs-24.
> Again, in package.el, what you say makes perfect sense. But in a
> source-based package manager, it seems better to handle this by having
> the package manager check out the correct revision.
That would misbehave if the user runs Emacs-24 and Emacs-25 at the
same time (and I'm one of the users who does that pretty much all the
time).
>> I agree that these needs aren't the most common ones, but you don't
>> gain anything by disallowing them, really.
> I think you gain something by enforcing a simpler directory naming
> convention.
Agreed. But you can simplify the naming convention by using a fixed
name for the metadata, instead of by disallowing version numbers in the
directory name.
>> AFAIK this is documented somewhere.
> The "somewhere" part is a big part of the issue. If I want to know
> something about package.el, maybe I should go to the Packages section
> of the manual, or maybe the Packaging section,
One of those two, yes.
> or maybe elpa.gnu.org, or maybe ELPA's README,
That should only be relevant for packaging issues related specifically
to GNU ELPA (and elpa.git).
> or maybe the Commentary in the source code of package.el, or the
> docstrings, or the comments ???
If it's sufficiently technical, yes.
> Regarding the format of packages on the server, I think this
> documentation is supposed to be at [2],
Sounds right.
> but it doesn't seem to actually be there.
Looks like a bug, then.
>> Actually "adding a directory to the load path" is only there by
>> accident: it should be done by the autoloads file.
> Does that mean M-x update-directory-autoloads will start inserting
> load-path manipulation calls into the generated autoload files?
No.
> Or should package.el roll its own autoload generation routine?
It does, indeed: autoload.el was designed to maintain autoloads within
an existing file, which can have any arbitrary "preamble".
> start if they want to optimize their init. It'd be helpful to know if
> the bottleneck was:
>
> * evaluating autoloads
> * processing dependencies
> * loading caches
> * activating packages that are no longer referenced in the init-file ??
> * etc
I don't know of anyone who has investigated this, so AFAIK noone knows
the answer. Maybe the time is spent in a silly useless routine that's
easy to optimize (I doubt it's the case, FWIW, but it's likely that it
can be sped up if needed).
Stefan
next prev parent reply other threads:[~2017-08-14 8:02 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
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 [this message]
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=jwvpobymw2l.fsf-monnier+Inbox@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=radon.neon@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 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.