Re: feature/integrated-elpa 4f6df43 15/23: README added

[Phillip Lord]

Eli Zaretskii <address@hidden> writes:

>> From: Achim Gratz <address@hidden>
>> Date: Sat, 15 Oct 2016 15:34:42 +0200
>> 
>> >> Except that it doesn't. Try this. Take Emacs 24.3, M-x package-install
>> >> org. Now do, M-x load-library org-html. As you might expect org-html is
>> >> duly loaded.
>> >
>> > How is this relevant to the issue at hand, though?  If you want to
>> > solve this problem, all you need to is place all the ELPA directories
>> > in load-path ahead of the standard ones, that's all.
>> 
>> How do you suppose the autoload for the no longer existing org-html will
>> be excised from the autoloads file in the old Emacs?
>
> Once again, how is this relevant to the directory structure of Lisp
> files?  Can a particular structure solve this problem, where other
> structures don't?

Yes. Package.el solves this problem quite nicely. We have:

~/.emacs.d/elpa/org-mode-1.6/org-html.el
~/.emacs.d/elpa/org-mode-1.8/ox-html.el

package.el solves the problem that org-html.el no longer exists simply
by not adding org-mode-1.6 to the load path. Nor does it load
"org-autoloads.el". So, even though org-html.el is still around on the
hard drive, it is ignored by emacs.

Now, as it happens, with the current directory organisation of Emacs, we
can solve the problem anyway, by doing the same trick in core. But,
currently, we don't.

And this could only work for org.el *because* org is in it's own
directory with its own autoloads file. For seq.el, for instance, it will
not work.

IIUC, in fact it's the org-mode folks actually view this as a
significant *disadvantage* to having org-mode in core. It's only because
this is the only way to get it into the tarball that they do it. Achim,
do I have this right?

There are a few other things that package.el does, which it would be
shame to loose. It checks dependencies for instance. So, say, I
installed assess.el into Emacs core using package.el as I suggest, and
it requires a newer version of seq.el than is available, package.el will
bitch about this very early.

We could achieve all of this without package.el, with copying and
checking. But why? package.el already does all of this.

Bottom line: package.el is a better way of handling packages than core
which is a legacy. Moving wholesale to it is probably not worth the
effort (at least not in the short term). But supporting it in core
definately is.

Phil