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

[Eli Zaretskii <eliz@gnu.org>]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: Achim Gratz <Stromeko@nexgo.de>,  emacs-devel@gnu.org
> Date: Sat, 15 Oct 2016 15:53:33 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Achim Gratz <Stromeko@nexgo.de>
> >> 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.

The same can be done with any other directory structure, in two steps:
(1) put the new directory first in load-path, and (2) don't load
org-autoloads.el.  Right?

> 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.

That's exactly what I meant: we can do this with any directory
structure.  IOW the directory structure is not relevant to this issue.

> 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.

So one solution would be to provide a separate autoloads file for each
package that lives on ELPA.  That again has nothing to do with the
directory structure.  Right?  (There could also be other solutions.)

> IIUC, in fact it's the org-mode folks actually view this as a
> significant *disadvantage* to having org-mode in core.

What is "this" that the Org folks see as a disadvantage?

> 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.

I don't see why we'd have to lose this.  No one said we are throwing
away package.el.  We are talking about _extending_ it.

> 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.

We need to adapt package.el to the new needs.  It was not written with
these goals in mind, so it needs to learn new tricks.  Throwing it
away is not acceptable, but neither is blindly accepting its current
assumptions, which were not designed for the use case we are
discussing.