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