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

[Achim Gratz]

Eli Zaretskii writes:
> 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?

You are missing that the order in which all these things happen becomes
important.  The newer autoload can only shadow the old one if it's
processed _before_, likewise initializing other Emacs packages might
inadvertently pull in old autoloads or definitions before things have
been rearranged by package.el.  This is not hypothetical, all of that
has already happened and users have suffered from it.  When they report
the resulting symptoms it is extremely difficult to tease out what
exactly happened, in which order and why, so it also wastes the time of
those folks who want to help them.

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

If you only want to look at that one-dimensional example, yes.  Real
Emacs installations are quite a bit more varied.  The tools we have
today to sove this problem make things more brittle when they should
become more robust.

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

I still don't get what you hope to gain from throwing things that don't
belong together (and aren't upstrem) in a single directory (only talking
about the code parts here, documentation can be pulled someplace else).

In fact, most of the packages that might be on ELPA already are in their
own subdirectories and the only thing you'll need to do is not generate
the first-level autoloads into loaddefs.el and instead have some
package-autoloads be generated by package.el.  Then create some default
package configuration with all these packages activated, but give the
user configuration preference so they can be deactivated.

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

Single-file packages in core that are duplicated on ELPA (if these even
exist, I haven't checked) can coexist just fine in a single directory if
you so desire.  They are orders of magnitude less complicated to deal
with.  But the total of these should still live in a separate package
directory that is created just to give them a home.

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

I've said it before and I will say it again just this one time: If Emacs
takes packetization of the core seriously, then the "hard core" should
contain just the stuff that is needed for bootstrapping Emacs.
Everything else should be a package.  Single-file packages would live in
one directory together, and multi-file packages would be in their own
directory each.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada