On 10/31/2012 06:22 PM, Johan Tibell wrote: > Hi all, > > Sensible defaults are important to provide a smooth user experience, > especially for first-time users. There are a few areas where I think cabal > could improve its default behavior. In particular, here are a couple of > changes I would like to make: > > *cabal build should imply cabal install --only-dependencies > * [--snip--] > The reasons I've heard for not having build imply installing dependencies > is that users might not want packages to be downloaded from the internet, > unless they explicitly use cabal install. While that's a fair point, I > think it should be an opt-out rather than an opt-in because:
It might be an option to do what Maven (shudder) does here: Have an explicit "offline" mode (switchable by config or cmdline option) which simply blocks any online activity with an error message. > > - Users will end up have to install the dependencies anyway and there's > typical no other options than installing them from Hackage. > - Many users use cabal install instead of cabal build, for the reasons > given above, making it a moot point. > > Proposal: add a --install-dependencies flag to cabal build that defaults to > True. +1. [--snip--] > *Sandboxing should be used by default* > +1. > This follows the "make it correct, then make it fast" principle. Sandboxing > helps with a certain class of build problems, namely problems due to two > different builds overwriting each others' dependencies in the shared > package database. This problem shows up as a dangerously sounding cabal > warning message, mentioning the --force-reinstalls flag. That, and you end up with broken packages due to no fault of your own (using the default mode). That's simply bad from a usability perspective. > Sandboxing is an imperfect solution to this problem, requiring more > rebuilding of packages than strictly necessary. A final solution would > involve something like a Nix-style, append-only package database. The Nix > solution is being worked on, as part of GSoC, but it's a difficult problem > and it requires more wide-reaching changes (e.g. to ghc, ghc-pkg, ghci, and > cabal). Since sandboxing is working today (with a few minor tweaks yet to > be done) and it can be transparently replaced with a better solution once > we have one, I think we should enable it by default in 1.18. > (Drools about the prospect of true Nix-style package database -- hope's to hoping that happens at some point.) > > *We should add a cabal run command* > +1. _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel