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

[Phillip Lord]

Eli Zaretskii <address@hidden> writes:

>> From: Achim Gratz <address@hidden>
>> 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, and it restarting Emacs
were the solution then neither of us would, I expect, be complaining.

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.

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.

Currently, package.el does not do this for core installed files, but
does do this for package.el installed files. And, package.el could
*only* be made to do this, if a package is in its own directory.


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

>> If you think you don't need this, I have done some experiments to excise
>> the remnants of a built-in package from Emacs' data structures
>> (autoloads and customization), but there really isn't any supported way
>> to do that and I consider the whole thing incredibly brittle since I
>> need to manipulate internal data structures to do that.  At the minimum
>> you'd need official support for re-defining an autoload so it stops
>> pointing at the wrong load-file.
>
> These problems need to be attacked and solved.  But saying that
> instead of solving them we should fundamentally change our lisp/ tree
> is IMO not the right way.  It's akin to searching the keys where the
> streetlight is, not where they were lost.  We need to define the goal,
> and then work towards implementing it, not the other way around.

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.

Phil