Re: Interoperation between package managers

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> 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