[jfischoff]

Sandboxing is merely a stop-gap to reproducible builds (I hope). Nix style multiple instances of the same version of an installed package will lead to better reuse, thus faster builds.

If the fingerprints can be made precise enough, binary caches can be distributed from trusted parties, similar to what other package managers do.

[lomnakkus]

Hopefully we can also get real module interfaces[0] in the not-too-distant future so we can at least lessen some of the spurious diamond dependency problems that tend to crop up once in a while.

[0] http://plv.mpi-sws.org/backpack/

[jfischoff]

I think for modules to help here, the interface would have to not change between versions, useful for ByteString, not so much for Yesod.

As it stands now, cabal's constraint solver will prevent the installation of a package that indirectly depends on two different versions of the same package. This is too bad, because it is not necessarily true the package will fail to install.

Ideally cabal could somehow know which types are exported and which are not. In lieu of that, I personally I would prefer to have a chance of a successful install, and get a compiler error if things really do conflict, instead of a conservative constraint solver error.

[lomnakkus]

Certainly it's not going to be a panacea, but if you are familiar with O'Caml or SML you can hopefully sort of see how it's going to be of immense help when dealing with "trivial" package upgrades and such.

Hopefully Yesod will also (if/when this Backpack thing comes to fruition) expose some sort of stable interface for, say, the 5.x series. I think Michael has been very good about keeping things compatible, given the current constraints on the ecosystem, so I imagine he'd be very interested in declaring a stable interface explicitly if that were possible.

[cordite]

Just a thought, why not have fingerprints be like a Merkle tree?

A (naive) example: a built package has the hash derived from the package identity and all dependency hashes at compile / link time.

[jfischoff]

This is the plan I think, or something like it.

Currently package are referred to by unique hash that sort of works this way, but there are few unfortunate restrictions in GHC and cabal that need to be lifted to allow future installations to not conflict with past installations (multiple instances of the same version, right now there can only be one foo-0.1.0.0 even though it also has a unique hash).

[zimbatm]

Note that it's not optimal either, a small variation in a root dependency can trigger the recompilation of the whole tree, even if the change is backward-compatible.