What's next?

[Bardur Arantsson]

On 2013-09-06 01:04, Johan Tibell wrote:
> You raise a good point that sandboxing only addresses the issue of
> conflicts between two projects (that want to use different
> dependencies), but not the issue of actually using two different
> versions of a package (at different versions) in a single project*.
> The latter is valuable but also a bit tricky. We'd need to make sure
> that the two versions of the dependencies are private dependencies of
> some other dependencies. For example, it's OK to use two different
> versions of Parsec as long as you don't pass values from one version
> to the other.

Can't this be determined (conservatively) from the Exposed-modules? If
you allow declaration of dependencies to be split into two -- one list
of dependencies for the exposed-modules and one list of the internal
modules of a package -- it seems it should be a lot easier to handle
this. The package hash would be made up only of its Expose-modules and
their dependencies. It would then be up to the author of the .cabal file
to ensure that the set of dependencies of the Exposed-modules is minimal.

IMO the *validation-only* portion of this would also be an excellent
standalone feature -- it would let package authors ensure "hygiene" wrt.
dependencies. (That is, you're only exposing what you're expecting and
there's no way to acccidentally expose an implementation detail via
accidental reuse of a dependency's types.).

I know very little of GHC/Cabal internals, so I don't know how much work
it would take to implement just the validation portion of this, but I
think it might make a good self-contained first step towards a full
implementation of private packages.

Anyone with more knowledge of internals care to chime in?

Regards,