Re: Summary and next steps for (package-initialize)

[Stefan Monnier]

> What about packages that include accommodations to, and dependencies
> on, other packages?  Imagine the following situation:
>
>  . package B modifies its behavior if package A is loaded
>  . the user sets up package-load-list such that package B should be
>    loaded, but package A should not be
>  . package B is activated by package-initialize after package A was
>    activated, so B modifies its behavior
>  . package-initialize unloads A
>  . the result is that B behaves as if A is loaded, contrary to what
>    the user wanted, and will probably produce weird errors at some
>    point, or subtly incorrect behavior
>
> I don't think we can claim in this case that there's a bug in either
> of these two packages, can we?  Or is there a way for the packages to
> be prepared for such situations?

[ Note: in the above "package A" and "package B" really refer to
  the files A-autoload.el and B-autoload.el, which aren't really
  "packages".  I'll try to be more precise below.  ]

I guess B-autoload.el could add a function to a "A-autoload-unload-hook".

But things can get worse: B-autoload.el could not only behave differently
depending on whether A-autoload.el was loaded, but it could also cause
A.el to be loaded, in which case unloading A-autoload.el won't
be sufficient, unless we arrange for the unloading of A-autoload.el to
also unload A.el.

Again, here we're back to the obvious observation that do+undo is a poor
and complicated way to do nothing.


        Stefan