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

[Eli Zaretskii]

> From: address@hidden (Phillip Lord)
> Cc: address@hidden,  address@hidden
> Date: Tue, 18 Oct 2016 11:52:17 +0100
> 
> > That's exactly what I meant: we can do this with any directory
> > structure.  IOW the directory structure is not relevant to this issue.
> 
> I think that this is incorrect. In this case, we can do this with the
> directory structure that we have at the moment, and for org-mode,
> because org-mode is a) in a directory of it's own and b) has it's own
> loaddefs. This is not true for many of the files in ./lisp.

When I said "we can do this" I didn't mean "without any changes" or
"for free".  We will have to make changes, both in how loaddefs are
generated, and in the build.  My point is that these changes are not
difficult, since we already do that for several distinct packages in
the core.  We just need to do that for more packages, that's all.

> The point here is that load-path is *directory* based. As it stands, we
> cannot exclude some files in one directory.

I don't see any need to exclude files.  If a newer version of a
package is installed outside of the Emacs lisp/ tree, the directory of
that package needs to be earlier in load-path than the main lisp/
directory and its subdirectories.  Again, not hard to arrange.

> > 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.)
> 
> I think that it is evident that there could be other solutions. Emacs is
> Turing complete so any computable solution that you can image is
> possible. The question is which is easiest.

They are all easy.

> package.el already does all of this.

Once again, package.el in its current form was never meant to be used
in the capacity we are talking about.  So using it without changes for
the job we are discussing is wrong, because it would mean to subdue
our directory organization to decisions made for a completely
different use case.

In any case, such a solution was already rejected, both by John and
myself.  So let's not argue about this anymore; let's instead see
which changes are needed in package.el to support the preferred
directory structure in core, even when some of the bundled packages
live on ELPA.

> >> 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.
> 
> Just so that we can keep a particular directory structure?

Yes!

> > 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.
> 
> No, but it's current behaviour makes a lot of sense to me and is, I
> think, better than the monolithic structure we have in ./lisp.

Others, including myself, disagree.