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

[Eli Zaretskii <eliz@gnu.org>]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Wed, 19 Oct 2016 20:26:33 +0200
> 
> 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.

I understand that.  I just don't see why we couldn't do this in the
correct order, given that the meta-data which accompanies the update
of a package is correct.

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

I understand that in general having some bundled packages in another
repository makes things more complex, perhaps much more complex.  But
since the majority wants that, we will have to deal with that
complexity and solve it well enough to work in practice.

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

Simplicity of use for everyone and transparency for end users (who
shouldn't be concerned in which Git repo a given package is
maintained).

> 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 see no reasons that this couldn't be done without having a separate
directory per package.

> 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 see no reasons to have a separate directory for packages that come
bundled.

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

If you mean that those "packages" are downloaded by end users when
they install Emacs, and don't come with the release tarball, then this
is against the current agreements, AFAIU.  The current agreements are
that the ELPA packages are downloaded and installed in the Emacs tree
when the release is being tarred, and come in the bundle ready to be
used.