[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Monnier
Subject: Re: Summary and next steps for (package-initialize)
Date: Fri, 25 Aug 2017 07:51:32 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]