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

[Phillip Lord]

Achim Gratz <address@hidden> writes:

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

Yeah, it took me ages to work out. I got lots of very strange and
inconsistent behaviour before I tracked it down to a single (require
'org-html) -- in my own code, incidentally. I'd extended org to do what
I wanted, and didn't know about the exporter update.


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

This is what my branch does, and it's relatively simple to achieve. The
code is messy at the moment, and it also requires some updates to
package.el (because otherwise emacs -q will disable these "core"
packages which it shouldn't). But it is there.


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

Not so convinced that this would be good, just because it creates the
edge case of where a single-file package later becomes multi-file
package.

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

That would be my aim too, probably for Emacs-27.

Phil