Re: Interoperation between package managers

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

>> I'd probably want to also unify the two files into one (which would
>> likely hold the concatenation of <pkg>-pkg.el and
>> <pkg>-autoloads.el).
> I'm a little wary of this idea. It seems to me like <pkg>-autoloads.el
> is purely an implementation detail (or "build artifact") of the
> package manager, whereas <pkg>-pkg.el contains author-maintained
> metadata that should be checked into version control in the upstream
> repository.

My view is that <pkg>-pkg.el should be built from metadata stored
elsewhere (that's what we do in elpa.git).

>> I think it's very important to be able to have several versions of a
>> given package installed at the same time.
> This is another concept which makes a lot of sense in the
> tarball-from-ELPA workflow, but not much sense in the source-based
> workflow (where you don't need to save old versions because you can
> revert to any version at any 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).

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.

I agree that these needs aren't the most common ones, but you don't gain
anything by disallowing them, really.

>> Specific requests (especially patches) are very welcome here.
> Unfortunately, I can't contribute patches since I am already too busy
> maintaining my own package manager.  However, I can give some
> suggestions for things that need to be explained.

These look like info about the internals, and indeed we don't document
them very much.  Some of them are purposefully not documented ("use the
source, 'cause it might change").  But there's a a lot of room for
improvement anyway.  I'll see if I can improve on that.

> * What is the format of a package on the server?

AFAIK this is documented somewhere.

> * What does activating a package mean? Again, I know that it entails
>   evaluating the autoloads file and adding a directory to the load
>   path, but most people don't.

Actually "adding a directory to the load path" is only there by
accident: it should be done by the autoloads file.

> * Why is package-initialize so slow?

I don't know that it is, so I can't answer the question.

>   What are the bottlenecks when you
>   activate lots of packages?

I haven't looked into.  If you find performance problems,
M-x report-emacs-bug is probably the best option, so we can try to find
how to improve the situation.

> Maybe package.el is simple, but unless there's a clear statement that
> "this documentation covers exactly what package.el does", there's
> always the concern that more magic is going on, given how opaque the
> source code is.

The source code of package.el is not supposed to be opaque.  I wasn't
the original author and I didn't find it opaque when I looked at it.
So if it's opaque, maybe it's my fault, but I'm probably not the right
guy to fix it, then ;-)


        Stefan