Status of encapsulations in the modular dependency solver

[Edward Z. Yang]

Hello all,

I wanted to know what the status of the encapsulations feature in Cabal
is. Presented in HIW'11, the intent was for it to be used to support
private dependencies in Cabal.  However, while this is was implemented
in the modular solver, it looks like it was never wired up with Cabal
proper.  Andres, you mentioned you might be getting around to looking
at this again?  Since we have more fine-grained linker symbols in
GHC HEAD, this feature ought to work better.

In any case, when I was reviewing the HIW'11, I realized that the
semantics of encapsulations discussed there are not quite the ones you
might actually want.  In particular, there was an example where C
encapsulates its dependency on B, but if C has another
(non-encapsulated) dependency D which depends on B, now the global
choice of B (witnessed through C.D.B) and C.B are required to be the
same.

However, it might also be useful for these two dependencies to still
be different, even in this case.  In particular, it may be useful
to encapsulate a package *even if it shows up in the interface.*
Such packages can be used for:

- Building compatibility layers between multiple versions of a
  package (here, we want to build-depends on the same package
  multiple times, in an encapsulated way)

- Using the encapsulations feature to represent Backpack style
  mix-ins, where packages with holes are considered encapsulated.
  (I'm not 100% this is the right way to go about implementing
  this, but it's one possibility).

Cheers,
Edward