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

[Achim Gratz <Stromeko@nexgo.de>]

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.

>> Org-mode v1 comes with org-html. v1 is distributed through ELPA.
>> Org-mode v2 comes with ox-html. We upgrade v1 to v2, and v1 is removed
>> from the path. org-html is no longer loadable.
>
> org-html doesn't need to be loadable if it doesn't exist in the new
> version.  Again, nothing to do with load-path.

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.

>> My conclusion: having org-mode its own directory is a good thing. By
>> extrapolation, therefore, having most or all packages in their own
>> directory would be a good thing.
>
> The extrapolation is invalid, because while Org is a very large
> package, most other packages aren't.

Forget about Org.  The only reason it gets mentioned at all is that it
is moving fast enough to have already produced all the problems
mentioned so far _in the wild_, with actual users suffering the
consequences.  Each such failure can be easily demonstrated with a
package having just a single or two files.

>> > If package.el already knows how to unload the old features and load
>> > the new ones, it will continue doing this for any package, whether in
>> > or out of core.  Right?
>> 
>> With the example that I have given, this fails at the moment for
>> org-mode, specificially because org-mode is in core.
>
> I don't understand why it fails, but if it's a missing feature in
> package.el or in the infrastructure, we need to add that, in order to
> move to having bundled packages on ELPA.

Well, start with cleaning up load-path and autoloads in a way that any
built-in package can be cleanly deactivated: after deactivation Emacs
behaves as if the package wasn't present.

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.

Again, the results of those forays are still in (upstream) Org in
various places: testing/org-batch-test-init.el removes enough of the
Emacs' builtin Org package so that the tests actually use the correct
files, there's some more code in mk/org-fixup.el to deal with the
generation of some files that package.el can't produce in its current
state and then some checks in org-version (org.el) to warn about a mixed
installation.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds