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: Wed, 19 Oct 2016 08:51:39 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Achim Gratz <Stromeko@nexgo.de>
> >> Date: Tue, 18 Oct 2016 20:48:29 +0200
> >> 
> >> Eli Zaretskii writes:
> >> > That just means installing a new version needs to remove the previous
> >> > version's files first, that's all.  It has nothing to do with
> >> > load-path.
> >> 
> >> That's simply not an option when a user wants to install an updated ELPA
> >> package in his home directory while the system administrator keeps the
> >> Emacs installation as-distributed.  In other words, you'd kill _the_
> >> feature that package.el was supposed to give mere users and arguably the
> >> main selling point.
> >
> > If no better solution comes up, it would mean the user will have to
> > restart Emacs.  Hardly a catastrophe.
> 
> Eli, I think you are not taking the time here to understand the problem.
> Both Achim and I have thought the issue through

Those kinds of remarks are hardly constructive.  Please assume that
I've thought the issues through as best I could, and if I'm missing
some important details, those details should be put on the table
explicitly and discussed.

> and it restarting Emacs were the solution then neither of us would,
> I expect, be complaining.

I don't see why restarting won't be a solution.  If load-path was
re-arranged to put the latest version of a package first, and the
package's autoloads are on a file that has been regenerated, what else
is missing to make restart the correct solution?

> As Achim says, an org-html in the core installation cannot be removed
> because it comes as part of a packaged Emacs and needs admin
> privilleges; again, can be done, but not very good practice. The
> org-html in core can be shadowed but only by another file called
> org-html. More recent versions of org do not contain such a file.

If load-path is rearranged when a newer version of Org is installed,
and org-loaddefs are regenerated, then, after a restart, any 'load'
and 'require' will find the new files first, and the old ones will be
effectively invisible to Emacs.  Right?

> There are solutions to this, many of them hacky. The simplest solution
> is to NOT include the directory containing the old version of org in the
> load-path.

That solution will only work for packages in their own directories.
We want to have a solution that works even for files in common
directories.  I think rearranging load-path and regenerating the
autoloads will solve that as well.

> >> But in the situation explained by Phillip it _is_ loadable, even though
> >> it must not be.  If in fact you have an autoload pointing to a file that
> >> no longer exists or doesn't contain the autoloaded function anymore,
> >> then a modification of load-path after that autoload has been generated
> >> won't help at all.
> >
> > Restarting Emacs will solve that.
> 
> It will not, and does not.

Why won't it?  (The "does not" part just means package.el doesn't
currently do that, AFAIU, but it can be extended to do it.)

> I have defined my goal and a path toward it.
> 
> I believe that Emacs should have a single mechanism for managing
> packages, and that this mechanism is package.el. I am aware that this is
> a big change and have, therefore, presented an incremental path by which
> this can be trialed out without mass renaming or moves of files in core,
> and which also allows support for adding packages stored in ELPA to the
> core build which is a sensible goal put forward by John.
> 
> I will leave it there. If neither you or John want to go this way, I
> will stop.

I think we both indicated that we want to go this way, we just don't
want the Lisp files scattered among dozens of directories, each one
with a single file.  Yes, this is a goal that is harder to achieve,
but I don't yet see any fundamental difficulties on that path, just
some more work.

I think making such a change incrementally is worse than doing it at
once, as far as the directory structure is concerned.  We don't want
to change the directory structure several times, ideally not even
once.  But if some change is required, it should be done in one go, so
we need to decide on the structure up front.

Thanks.