Re: Is (provide 'foo) at the start good or bad?

[Davis Herring]

>  > > Because external packages don't know about the mutual dependency, and
>  > > shouldn't have to.  Multiple versions of the files may support the
>  > > same interfaces, some with and some without mutual dependency.  Etc.
>  >
>  > That was case #3, wasn't it?
>
> No.  You're missing the "multiple versions" case.  (Although GNU Emacs
> prefers to "support" 3rd party libraries by incorporating them, other
> Emacsen try to support third parties as independent projects, and that
> doesn't necessarily mean there's a blessed third party for each such
> library, either.)

(I think most of the productive ideas here have been stated.  Purely for
my edification:)  Why, if we have Av1 and Bv1, neither of which requires
the other (or at least only one requires the other), and Av2 and Bv2,
which are mutually dependent, can't we merge only the latter and have ABv2
(perhaps with one or two tiny files that let (require 'A) and (require 'B)
find it) while still leaving the old, independent versions separate?

...I suppose you could have the situation where Av1 requires Bv1, and then
Bv2 also requires Av1, and you'd like to not have to modify A.  But then
you could either make Av1.0.1 that just changes the `require's (not much
of a hassle since people that would need it are upgrading B anyway), or
else make A(+B)v2 (and a B stub) rather than Bv2 at all.  Right?

Later you said that the (mutually-dependent versions of the) libraries
might continue to be developed separately.  That seems odd to me, since
they will always be loaded together, and they might need to be upgraded
together.  But if it does happen, then perhaps the right thing is to put
`require's as late as possible and `provide's right before them, so that
both mutual recursion and `eval-after-load' will work (most of the time).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.