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

[Eli Zaretskii]

> From: Achim Gratz <address@hidden>
> Date: Wed, 19 Oct 2016 21:24:54 +0200
> 
> Alain Schneble writes:
> > Of course.  The order of directories in load path is always relevant.
> > Whatever structure we choose.
> 
> Good.  Now take that last step: if you want to be sure that you don't
> load something you don't want to be loaded, it must not be found via
> load-path at all times during the lifetime of the Emacs process.

That is inaccurate.  The accurate description would be "it must either
not be found via load-path, or not mentioned in any 'load' and
'require' form and in any autoload cookie.

> That precludes almost all solutions that depend on removal or
> shadowing during later steps in the initialization sequence and
> where not-yet-to-be-initialized packages become visible when
> initializing another package.

I don't see how you jump to that conclusion, except by assuming some
buggy or chaotic behavior on some other packages.

But we are not talking here about some obscure package downloaded from
some github spot.  We are talking about packages that today live in
core, and will (or at least should) still get the same amount of
attention from the Emacs developers when they are maintained on ELPA
as they do today.  So any assumptions of gross bugs like the ones you
evidently have in mind in those packages are simply invalid.  I
understand you have bumped into such problems, and I understand that
they could happen, but I disagree that we should account for them
happening in the packages that are the subject of this discussion for
longer than a few hours, exactly like we have today with any commit
that breaks some build somewhere.

Errors do happen, but if they are fixed soon enough, the design
doesn't have to take these errors into consideration, and doesn't have
to be robust against them.  (It is, of course, nice to have such
robustness where it comes for free or for a very low price, but not
where the price is high.)