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,