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, _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
