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 * If you're currently working on a package, the right [1] way to build it is as follows: cabal install --only-dependencies cabal build (Note that in HEAD cabal build implies cabal configure so that step is no longer necessary, unless you need set some configure flags.) However, this is unintuitive and repetitive and many users end up using cabal install instead. 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: - 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. Once we start installing dependencies by default, the very first run of cabal build may take a long time, especially if sandboxing is used, so I think we should output the following message before installing dependencies: "Installing dependencies. This may take a long time if this is the first time you build this package." *Sandboxing should be used by default* 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. 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. Since sandboxing will result in more rebuilding, we should also enabled parallel builds by default, as they typically speed up builds by a factor of 2. Finally I think we need to improve messaging. We could use the same messaging as above i.e. "Installing dependencies. This may take a long time if this is the first time you build this package." Adding sandboxing by default also makes it easier to depend on unreleased versions of packages, as it has an add-source <dir> sub-command for managing those. *We should add a cabal run command* This proposal will only affect a small group of users, but will give those users a better user experience and hopefully encourage them to use cabal the right way. When developing e.g. web apps using Snap, the user needs to build and run an executable. You can do this today by running cabal build dist/build/my-exe/my-exe but e.g. the Snap documentation instead encourages users to do cabal install my-exe Perhaps because it's shorter and requires less explanation of where cabal puts its build output. I think we could improve this use case by introducing a new command, cabal run, with the following parameters: cabal run <executable> <args> which would run cabal build dist/build/<executable>/<executable> <args> Comments welcome! Cheers, Johan 1. The reason this is the right way is that you don't want to litter your shared package database with unreleased packages, as other packages might be built against these unreleased packages by misstake.