What I found very confusing that the sequence
cabal install wurbel
and
cabal unpack wurbel cd wurbel-0.0 cabal install
Gives us *radically* different results. The first one usually fails
when I have a "hand-patched" package (already successfully installed)
that wurbel depend on. The second one will work.
My interpretation is that the former looks at the transitive
dependency tree and thus ignores my fixes that have lead to my current
cabal world. The latter only considers direct dependencies, which is
sufficient to resolve everything, since the necessary packages are
present, and the problematic dependencies (from hackage) get dropped.
What we need for the former is a flag that says:
"do not transitively chase dependencies of already installed packages"
This would greatly enhance the cabal experience for people who want to
try packages with HEAD GHC and thus may accelerate the adoption rate
of new GHC releases w.r.t. hackage.
Just some feedback while at it.
Cheers,
Gabor
On 3/1/13, Simon Peyton-Jones
Duncan, Mark, Simon
Here's another cry of pain: http://fluffynukeit.com/2013/02/reflections-after-a-hard-day-in-haskell-gui-...
"Cabal is a frustratingly constraining tool. Far too frequently I encountered packages that, when trying to install, would say installing this package will break a dozen others. If not that, then I often would be notified that the dependencies could not be resolved. "
What is frustrating that we KNOW how to fix this, don't we? (Allow multiple installations of package P-3.2.5, each depending on different versions of its dependencies.) We just need to liberate enough effort to do it.
Indeed, more people seem to be joining in with GHC/Cabal these days. How hard would it be to write a detailed description of the implementation changes needed to support side-by-side installations, and project-manage a group to do it?
Simon