creswick / cabal-dev

A wrapper program around cabal and cabal-install that maintains sandboxed build environments.

UPDATE: We recommend that people move away from cabal-dev, now that cabal-install supports sandboxes natively (in versions >= 1.18). Here's a blog post that describes how to use cabal-install sandboxes: http://chromaticleaves.com/posts/cabal-sandbox-workflow.html

Cabal Dev

Motivation

Performing consistent builds is critical in software development, but the current system of per-user and per-system GHC package databases interferes with this need for consistency. It is difficult to precisely identify the dependencies of a given project, and changes necessary to enable one project to build may render another project inoperable. If each project had a separate package database, each project could be built in a sandbox.

Usage

Cabal-dev is simple to use:

$ cd <cabalized project dir>
$ cabal-dev install

Cabal-dev will create a default sandbox named cabal-dev in the current directory. This will be populated with the project dependencies, which are built and installed into a package database within the sandbox. The first cabal-dev build of a project typically takes substantially longer than subsequent builds--don't worry, the artifacts created will be re-used on subsequent builds unless you remove the sandbox, or specify a different sandbox (with --sandbox= at the command line or the CABAL_SANDBOX environment variable; the command line flag takes precedence).

The project is then built, utilizing the sandboxed package database rather than the user database. (The GHC system database is still used. We recommend that only the core packages be installed to the system package database to reduce the potential for conflicts.)

cabal-dev install uses cabal-install to issue build and installation commands that place the project's build artifacts in the cabal-dev sandbox, as well as leaving the binaries in the familiar dist directory.

If you are developing multiple interdependent packages together, see the section below about building with private dependencies.

See cabal-dev --help for detailed usage information.

Ghci with cabal-dev

Cabal-dev 0.7.3.1 and greater are capable of launching ghci with the project's package database and local modules (if the package under development exposes a library).

# First, you must cabal-dev install the package to populate the
# package database:
$ cabal-dev install
....
<snip>
....
$ cabal-dev ghci
GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude>

The ghci shell should have access to all the libraries your application/library is using, as well as any modules that your library exposes.

Note that this is not quite as natural as your traditional ghci shell, namely: Source modifications are not visible without exiting, re-issuing cabal-dev install and cabal-dev ghci. This will eventually get better, but that's where things are right now. The reason for this is that cabal-dev ghci just issues ghci with the cabal-dev package database (and excluding the user package db, to best reflect what cabal-dev does when it causes compilation).

Building with private dependencies

Cabal-dev supports two different workflows for using un-released packages. The first makes the dependencies available in a sandbox-local Hackage. The second rebuilds the dependent package every time. If any of your private dependencies are unchanging (e.g. you had to patch a dependency to relax a package constraint) you will probably want to use add-source. If you are actively developing two packages that have dependencies on each other, you probably will prefer the second. You can mix and match these techniques seamlessly.

Using a sandbox-local Hackage

Cabal-dev also allows you to use un-released packages as though they were on hackage with cabal-dev add-source.

For example, the linux-ptrace and posix-waitpid packages were only recently uploaded to hackage. Previously, cabal-dev was used to build applications that depended on these two packages:

$ ls
linux-ptrace/  myProject/  posix-waitpid/
$ cd myProject
$ cabal-dev add-source ../linux-ptrace ../posix-waitpid
$ cabal-dev install

Note that cabal-dev add-source accepts a list of source locations.

Be careful, however, because packages that have been added are not tied to their original source locations any more. Changes to the linux-ptrace source in the above example will not be used by myProject unless the user issues cabal-dev add-source with the path to the linux-ptrace source again. This is similar to the cabal install step you may do now to enable a project to make use of changes to a dependency.

There is currently one additional requirement when using cabal-dev add-source. The projects that are add-source'd must generate sdists that will build. Cabal-dev currently uses sdists to transport the dependencies into the sandbox, so the project will not build if critical files are left out of the sdist. Note that the packages do not need to sdist cleanly, most warnings are acceptable, so this is rarely a problem.

Building multiple packages together

For packages that are being actively developed together, recent cabal-install (> 0.10) provides another option: specify all of the source directories together on the cabal-install command line. For example, say we're developing a Web application that depends on a helper package that we use for other Web projects as well. We keep making changes to both the application and its helper package. To build both packages together:

$ ls
my-webapp/  webapp-helpers/
$ cabal-dev install my-webapp/ webapp-helpers/

Note that this is a feature of newer cabal-install and is not limited to use with cabal-dev, but cabal-dev makes it more useful by keeping the development code isolated from other builds.

The disadvantage of this approach is that it can be slow. When you have not made changes to a dependency, cabal-install will re-link and reinstall it anyway (although it does avoid recompilation when it's not necessary). Use the add-source mechanism if you have a dependency that changes very infrequently.

cabal-dev's Issues

Hide everything from the global package database

cabal-dev hides the user package database, but not the global package database. More problems could be avoided if it hid the global package database as well. I believe that capri does this.

root-cmd in ~/.cabal/config should be ignored

As discussed with j3h, the Haskell Platform's flavor of cabal-install will generate a ~/.cabal/config with root-cmd: sudo by default. This setting currently gets picked up for sandboxed builds, resulting in password prompts and/or root ownership of some files/directories in the sandbox. Since the root-cmd should only be useful for truly --global builds, so cabal-dev should probably ignore it.

Sensible use of cabal-dev update?

If I try to build a project that has a bunch of dependencies, cabal-dev fails because I haven't run cabal-dev update in my sandbox. This surprised me a bit. I'm not very sure how to proceed - run cabal-dev update before every Hudson build, or ... something else?

cabal-dev library

For web development especially, incremental compilation is very useful. In Yesod we have a yesod devel command that accomplishes this. We are also looking into using the shaker package which appears to use very similar mechanisms. They both use the cabal library inteface to build the packages. To efficiently use cabal-dev instead of cabal, these tools need a callable library.

Allow specification of specific cabal-install binaries

It would be great to be able to specify which cabal-install binary to use, either via config file and/or a command line parameter.

cabal-dev ghci won't start

I'm having trouble starting an interactive session with cabal-dev ghci. Here's a minimal way to reproduce:

$ mkdir bug
$ cd bug
$ echo 'name:                bug
version:             0.1.0.0
build-type:          Simple
cabal-version:       >=1.8

library
  exposed-modules:   Bug
  build-depends:     base >= 4' > bug.cabal
$ echo 'module Bug where' > Bug.hs
$ cabal-dev configure
$ cabal-dev ghci
cabal-dev: user error (Warning: The 'license-file' field refers to the file 'LICENSE' which does not
exist.
Warning: cannot determine version of /u/afoltzer/.cabal/bin/fake-ghc-cabal-dev
:
"== GHC Arguments: Start ==\n--numeric-version\n== GHC Arguments: End ==\n"
/usr/bin/ar: dist/build/Bug.o: No such file or directory
)

Here are the relevant versions:

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
$ cabal --version
cabal-install version 0.13.3
using version 1.14.0 of the Cabal library 
$ cabal-dev --version
cabal-dev 0.9.1
built with Cabal 1.14.0

Add a runtime check of GHC version to warn about issues

Due to http://hackage.haskell.org/trac/ghc/ticket/4072, we should check the version of GHC and warn that GHC >= 6.12 && < 6.12.3 might have problems with linking local versions of libraries.

cabal-dev appears to depend on recent cabal install

For various reasons, I have ${HOME}/.bin in my path earlier than where the Haskell Platform is. I also have a version of cabal install in there which then gets picked up rather than the standard Haskell Platform one. In the usual case where this is more recent than HP, it's helpful.

However, recently I've upgraded from GHC 6.10.3 to a fresh GHC 6.12.3 and Haskell Platform 2010.2.0.0. This means that the cabal-install I'm using is out of date.

When I ran
cabal install cabal-dev
cabal-dev install vector

I then got

[18 of 19] Compiling Data.Vector.Mutable ( Data/Vector/Mutable.hs, dist/build/Data/Vector/Mutable.o )
[19 of 19] Compiling Data.Vector      ( Data/Vector.hs, dist/build/Data/Vector.o )
Registering vector-0.7.0.1...
cabal: vector-0.7.0.1: dependency
"primitive-0.3.1-1145bca6b1bbfb5f69c784fbca21aab2" doesn't exist (use --force to override)
cabal: Error: some packages failed to install: vector-0.7.0.1 failed during the building phase. The exception was:
ExitFailure 1

It didn't occur to me for a while that my cabal install could be the problem. Before, it was cabal-install 0.8.2 on version 1.8.0.2 of Cabal. I then tried cabal install cabal-install to upgrade this and cabal-dev worked as expected. Note that this is the same version of the cabal-install package (0.8.2) but on a more recent Cabal.

So I'm guessing that there may some kind of hidden dependency involved. That said, it seems like sort of a weird corner case to account for (people having old versions of cabal install lying around)... maybe the only way to solve it is by having an FAQ entry of the sort "Q: when I do X, Y happens? A: have you tried re-install cabal-install?"

buildopts

I am trying to create a cabal-dev repo with many added sources. If I use buildopts before installing, I get the below. After installing I get nothing.

cabal-dev: user error (Warning: cannot determine version of
/home/gweber/.cabal/bin/fake-ghc-cabal-dev :
"== GHC Arguments: Start ==\n--numeric-version\n== GHC Arguments: End ==\n"
cabal: yesod-head-0.9.3.2: dependency
"aeson-native-0.3.3.1-98db155088bf1e4fe25eee143e7d79ca" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"blaze-builder-0.3.0.1-40bc4a9d191000391661a4f472847d9d" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"blaze-html-0.4.2.1-b4b755edbc20ee4c38f0484cd2505c9a" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"case-insensitive-0.3.0.1-e3082d6f20a7e196959ec07a62d6b8d2" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"cereal-0.3.4.0-ac6f38965e85c88060f151ef4401059d" doesn't exist (use --force
to override)
yesod-head-0.9.3.2: dependency
"clientsession-0.7.3.3-ada300384b647b100453dc50b5193b21" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"cookie-0.3.0.1-bd6c52c129f8d62bc8ad913e41125f1d" doesn't exist (use --force
to override)
yesod-head-0.9.3.2: dependency
"data-object-0.3.1.7-1b5b49600773411c024f076c379ca4bc" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"data-object-yaml-0.3.3.5-dd1cbd8b01ae3be37ba580fc6c7f96ed" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"enumerator-0.4.15-82060e833479643f84af2b4e2d75b115" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"failure-0.1.0.1-3019bd36bda778259652dbe2965fc6d0" doesn't exist (use --force
to override)
yesod-head-0.9.3.2: dependency
"hamlet-0.10.4-bb24209b21452f5ffb6d0197afa86e56" doesn't exist (use --force to
override)
yesod-head-0.9.3.2: dependency
"http-types-0.6.6-292f77d669bb1dc296cfcdc8eefa3934" doesn't exist (use --force
to override)
yesod-head-0.9.3.2: dependency
"monad-control-0.2.0.3-1a49978417abc284a45378c7146cedb2" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency "parsec-3.1.2-08007cf42cd4e981e0488ed6a5398c17"
doesn't exist (use --force to override)
yesod-head-0.9.3.2: dependency
"path-pieces-0.0.0-f944044c868f26987bf0ae8be760da71" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"shakespeare-0.10.2-8537834157b982f56aff9e29556c3c6f" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"shakespeare-css-0.10.2-457e7134b2692a50c424e28359cf654a" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"shakespeare-js-0.10.2-3288e8e5fc2d9f660b6d4a1b99bec6e4" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"strict-concurrency-0.2.4.1-b4d5efdc564303c5a1765b59abc41067" doesn't exist
(use --force to override)
yesod-head-0.9.3.2: dependency
"text-0.11.1.9-03c4587b965aaf42fe75b60a37754c28" doesn't exist (use --force to
override)
yesod-head-0.9.3.2: dependency
"transformers-0.2.2.0-7341f4d82874561a0431f4b264319cf8" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency "vector-0.9-fad267ce69c607409dc09cf46bbc92c2"
doesn't exist (use --force to override)
yesod-head-0.9.3.2: dependency "wai-0.4.2-44755deccb1601c67e5af04d51f45a34"
doesn't exist (use --force to override)
yesod-head-0.9.3.2: dependency
"wai-extra-0.4.4-41bd2e2741aab3eba4b464c9cb26a223" doesn't exist (use --force
to override)
yesod-head-0.9.3.2: dependency
"yesod-0.9.3.1-97577ebc1ee567d0586eef7759af3ad0" doesn't exist (use --force to
override)
yesod-head-0.9.3.2: dependency
"yesod-auth-0.7.5-c4f46c0c6847169f911f423916966402" doesn't exist (use --force
to override)
yesod-head-0.9.3.2: dependency
"yesod-core-0.9.3.3-fc70ae90a004d15eb0f3a94e932c7053" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"yesod-default-0.4.0-c6f0c76b3c534796148ec0936a890a72" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"yesod-form-0.3.3-3bb95cddf0fbaa98ec327a57c90e79b3" doesn't exist (use --force
to override)
yesod-head-0.9.3.2: dependency
"yesod-json-0.2.1-f2a2e632652269a083d551e186edd577" doesn't exist (use --force
to override)
yesod-head-0.9.3.2: dependency
"yesod-newsfeed-0.3.1-cc8b76dcc4fd18025c1c23d0fe60d802" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"yesod-persistent-0.2.1-438edc00e3af83c46008102a01b5646e" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"yesod-sitemap-0.2.1-c7c07d844ac4efbfcd8c87b16c737e0e" doesn't exist (use
--force to override)
yesod-head-0.9.3.2: dependency
"yesod-static-0.3.1.2-7ea5ef5f78d8d908901a6e4c4fa3c4b9" doesn't exist (use
--force to override)
)

Allow to specify sandbox location via environment variable

It would be convenient to be able to specify the default sandbox location (which currently seems hard-coded to ./cabal-dev) via an environment variable. The -s/--sandbox=DIR option should have always precedence over the location set via an environment variable.

Automate uninstallation of packages

Please.

Run-time check to verify the Cabal version that cabal-install was built with

cabal-dev requires that the invoked cabal-install was built with Cabal >= 1.8.0.6, but this is a run-time check, so it can not be sensibly checked during the cabal-dev build.

This has proven to be an issue, since it is difficult to diagnose and many people run cabal-install with slightly older versions of Cabal.

Adjust paths after cabal-dev folder move

It took me a little bit to understand what needs to be updated after moving the cabal-dev folder. Mainly a search and replace in the packages directory, and cabal-dev ghc-pkg recache.

It would be nice if there was a cabal-dev recache that took care of both of these steps for us.

cabal-dev install fails to resolve dependencies for new yesod project

I am running Windows XP SP3 with Haskell Platform 2012, in a mingw shell. Here are the original repro steps:

1. cabal install yesod-platform
2. Make sure yesod is in your path
3. yesod init -- call the project "cabaldev-bugtest"
4. cd cabaldev-bugtest
5. cabal --dry-run install
6. cabal-dev --dry-run install

cabal successfully resolves the project's dependencies (right now on my system all it wants to install is persistent-sqlite). cabal-dev does not:

[Peter Berry@rhuidean cabaldev-bugtest]$ cabal-dev --dry-run install
Resolving dependencies...
cabal.exe: Could not resolve dependencies:
trying: cabaldev-bugtest-0.0.0 (user goal)
trying: http-conduit-1.4.1.8 (dependency of cabaldev-bugtest-0.0.0)
trying: socks-0.4.1 (dependency of http-conduit-1.4.1.8)
trying: cereal-0.3.5.2 (dependency of socks-0.4.1)
trying: attoparsec-0.10.2.0 (dependency of http-conduit-1.4.1.8)
next goal: yesod-platform (dependency of cabaldev-bugtest-0.0.0)
rejecting: yesod-platform-1.0.4.2 (conflict: cereal==0.3.5.2, yesod-platform => cereal==0.3.5.1)
rejecting: yesod-platform-1.0.4.1, 1.0.4, 1.0.3.4, 1.0.3.3, 1.0.3.2, 1.0.2,
1.0.1, 1.0.0 (conflict: attoparsec==0.10.2.0, yesod-platform => attoparsec==0.10.1.1)
rejecting: yesod-platform-0.10.3, 0.10.2 (conflict: cabaldev-bugtest => yesod-platform>=1.0 && <1.1)

You can still repro if you delete everything in the cabaldev-bugtest directory except the .cabal file and cabal-dev directory, and use cabal --config-file=cabal-dev/cabal.config. The .cabal file itself can also be simplified a bit. See https://github.com/HairyDude/cabaldev-bugtest for a test case.

-v3 logs are here: https://gist.github.com/2933107

`build` command parsed as a flag when using sandbox named `build`

When using a sandbox directory called build, the cabal build command is somehow misinterpreted:

$ cabal-dev -s build configure
Resolving dependencies...
Configuring foo-0.1.0.0...
$ cabal-dev -s build build
cabal: Unrecognised flags: build

However, specifying no sandbox, or a sandbox of a different name, seems to make everything work.

$ cabal-dev -s cabal-dev configure
Resolving dependencies...
Configuring foo-0.1.0.0...
$ cabal-dev -s cabal-dev build
Building foo-0.1.0.0...
Preprocessing library foo-0.1.0.0...
Registering foo-0.1.0.0...

add-source tarball

If I understand correctly, cabal-dev add-source uses sdist to copy dependencies to a sandbox. For various reasons, however, some packages cannot be effectively packaged using sdist. Perhaps it would make sense if add-source could accept a tarball in addition to the usual directory?

cabal-dev does install depencies of test suites

cabal-dev does not install a dependency which is only referred from an test suite stanza of a cabal file.

Should get --extra-include/lib-dirs from ~/.cabal

For maximal usability for people that can't install stuff to system directories, cabal-dev should adhere to extra-include/lib-dirs flags given in .cabal. Or even, better, support having additional config files, where things like these could be specified.

Cabal resuming install??

When i open my cabal installer it goes directly on to install then when i click install it doesn't work????

PLEASE HELP ME!!!!!!

implement cabal-dev ghci

This may be as simple as invoking a command like this:
ghci -package-conf cabal-dev/packages-7.0.1.conf/ -no-user-package-conf
where cabal-dev is the sandbox directory.

This doesn't incorporate modules from the project under development, if it is not a library, but it does work for libraries.

Print warning when source for add-source has changed

I don't know if you feel this is technically easy, or worth implementing, but I thought I'd make you aware of a misunderstanding I encountered; I posted a question regarding it (and answered it myself) on stackoverflow:
Using the --reinstall flag with cabal-dev

cabal-dev doesn't build with profiling turned on

The command cabal install cabal-dev --enable-executable-profiling fails. Output from a variant of this command using runghc Setup.hs is included below.

crabgrass:~/inst/cabal-dev-0.8% runghc Setup.hs configure --user --enable-executable-profiling && runghc Setup.hs build

Setup.hs:7:48:
    Warning: In the use of `buildVerbose'
             (imported from Distribution.Simple.Setup):
             Deprecated: "Use buildVerbosity instead"
Configuring cabal-dev-0.8...

Setup.hs:7:48:
    Warning: In the use of `buildVerbose'
             (imported from Distribution.Simple.Setup):
             Deprecated: "Use buildVerbosity instead"
Unpacking to dist/build/cabal-install-0.8.2/
Building cabal-dev-0.8...
Preprocessing executable 'ghc-pkg-6_8-compat' for cabal-dev-0.8...
[1 of 1] Compiling Main             ( src/GhcPkgCompat.hs, dist/build/ghc-pkg-6_8-compat/ghc-pkg-6_8-compat-tmp/Main.p_o )
Linking dist/build/ghc-pkg-6_8-compat/ghc-pkg-6_8-compat ...
Preprocessing executable 'fake-ghc-cabal-dev' for cabal-dev-0.8...
[1 of 2] Compiling Distribution.Dev.GhcArgs ( src/Distribution/Dev/GhcArgs.hs, dist/build/fake-ghc-cabal-dev/fake-ghc-cabal-dev-tmp/Distribution/Dev/GhcArgs.p_o )
[2 of 2] Compiling Main             ( src/FakeGhc.hs, dist/build/fake-ghc-cabal-dev/fake-ghc-cabal-dev-tmp/Main.p_o )
Linking dist/build/fake-ghc-cabal-dev/fake-ghc-cabal-dev ...
Preprocessing executable 'cabal-dev' for cabal-dev-0.8...
[ 1 of 19] Compiling Distribution.Dev.MergeCabalConfig ( src/Distribution/Dev/MergeCabalConfig.hs, dist/build/cabal-dev/cabal-dev-tmp/Distribution/Dev/MergeCabalConfig.p_o )
[ 2 of 19] Compiling Distribution.Dev.RewriteCabalConfig ( src/Distribution/Dev/RewriteCabalConfig.hs, dist/build/cabal-dev/cabal-dev-tmp/Distribution/Dev/RewriteCabalConfig.p_o )

Implicit import declaration:
    Warning: In the use of `catch'
             (imported from Prelude, but defined in System.IO.Error):
             Deprecated: "Please use the new exceptions variant, Control.Exception.catch"
[ 3 of 19] Compiling Distribution.Dev.GhcArgs ( src/Distribution/Dev/GhcArgs.hs, dist/build/cabal-dev/cabal-dev-tmp/Distribution/Dev/GhcArgs.p_o )
[ 4 of 19] Compiling Distribution.Dev.Utilities ( src/Distribution/Dev/Utilities.hs, dist/build/cabal-dev/cabal-dev-tmp/Distribution/Dev/Utilities.p_o )
[ 5 of 19] Compiling Distribution.Dev.InterrogateCabalInstall ( src/Distribution/Dev/InterrogateCabalInstall.hs, dist/build/cabal-dev/cabal-dev-tmp/Distribution/Dev/InterrogateCabalInstall.p_o )
[ 6 of 19] Compiling Distribution.Dev.TH.DeriveCabalCommands ( src/Distribution/Dev/TH/DeriveCabalCommands.hs, dist/build/cabal-dev/cabal-dev-tmp/Distribution/Dev/TH/DeriveCabalCommands.p_o )
[ 7 of 19] Compiling Paths_cabal_dev  ( dist/build/autogen/Paths_cabal_dev.hs, dist/build/cabal-dev/cabal-dev-tmp/Paths_cabal_dev.p_o )
[ 8 of 19] Compiling Distribution.Dev.CabalInstall ( src/Distribution/Dev/CabalInstall.hs, dist/build/cabal-dev/cabal-dev-tmp/Distribution/Dev/CabalInstall.p_o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package bytestring-0.9.2.0 ... linking ... done.
Loading package zlib-0.5.3.1 ... linking ... done.
Loading package array-0.3.0.3 ... linking ... done.
Loading package containers-0.4.1.0 ... linking ... done.
Loading package pretty-1.1.0.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package filepath-1.2.0.1 ... linking ... done.
Loading package old-locale-1.0.0.3 ... linking ... done.
Loading package old-time-1.0.0.7 ... linking ... done.
Loading package unix-2.5.0.0 ... linking ... done.
Loading package directory-1.1.0.1 ... linking ... done.
Loading package tar-0.3.1.0 ... linking ... done.
Loading package transformers-0.2.2.0 ... linking ... done.
Loading package mtl-2.0.1.0 ... linking ... done.
Loading package parsec-3.1.1 ... linking ... done.
Loading package network-2.3.0.4 ... linking ... done.
Loading package HTTP-4000.1.1 ... linking ... done.
Loading package process-1.1.0.0 ... linking ... done.
Loading package Cabal-1.11.2 ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
src/Distribution/Dev/CabalInstall.hs:1:1:
    cannot find normal object file `dist/build/cabal-dev/cabal-dev-tmp/Distribution/Dev/InterrogateCabalInstall.o'
    while linking an interpreted expression
zsh: exit 1     runghc Setup.hs build

Please upload cabal-dev for haskell-platform to hackage

I see you have already merged a fix that makes cabal-dev
compatible with the current version of the Haskell Platform,
2012.2.0.0:

#55

Thanks! But cabal install cabal-dev still fails.
Could you please just bump the version number in the
cabal file and upload it?

Thanks,
Yitz

n^2 "installing executables"

In a cabal file with 4 executables, I seem to get 16 Installing executable.

This makes cabal-dev install take a pretty long time if I have a lot of executables in my cabal file (14 fwiw)

Hopefully this is just something silly and not something fundamental that we're stuck with?

Installing LICENSE to
/tmp/cabal-dev-huh/cabal-dev//share/doc/cabal-dev-huh-0.1/LICENSE
Installing executable(s) in /tmp/cabal-dev-huh/cabal-dev//bin
Creating /tmp/cabal-dev-huh/cabal-dev//bin (and its parents)
Installing executable dist/build/x1/x1 to /tmp/cabal-dev-huh/cabal-dev//bin/x1
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x1
Installing executable dist/build/x2/x2 to /tmp/cabal-dev-huh/cabal-dev//bin/x2
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x2
Installing executable dist/build/x3/x3 to /tmp/cabal-dev-huh/cabal-dev//bin/x3
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x3
Installing executable dist/build/x4/x4 to /tmp/cabal-dev-huh/cabal-dev//bin/x4
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x4
Creating /tmp/cabal-dev-huh/cabal-dev//bin (and its parents)
Installing executable dist/build/x1/x1 to /tmp/cabal-dev-huh/cabal-dev//bin/x1
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x1
Installing executable dist/build/x2/x2 to /tmp/cabal-dev-huh/cabal-dev//bin/x2
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x2
Installing executable dist/build/x3/x3 to /tmp/cabal-dev-huh/cabal-dev//bin/x3
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x3
Installing executable dist/build/x4/x4 to /tmp/cabal-dev-huh/cabal-dev//bin/x4
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x4
Creating /tmp/cabal-dev-huh/cabal-dev//bin (and its parents)
Installing executable dist/build/x1/x1 to /tmp/cabal-dev-huh/cabal-dev//bin/x1
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x1
Installing executable dist/build/x2/x2 to /tmp/cabal-dev-huh/cabal-dev//bin/x2
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x2
Installing executable dist/build/x3/x3 to /tmp/cabal-dev-huh/cabal-dev//bin/x3
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x3
Installing executable dist/build/x4/x4 to /tmp/cabal-dev-huh/cabal-dev//bin/x4
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x4
Creating /tmp/cabal-dev-huh/cabal-dev//bin (and its parents)
Installing executable dist/build/x1/x1 to /tmp/cabal-dev-huh/cabal-dev//bin/x1
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x1
Installing executable dist/build/x2/x2 to /tmp/cabal-dev-huh/cabal-dev//bin/x2
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x2
Installing executable dist/build/x3/x3 to /tmp/cabal-dev-huh/cabal-dev//bin/x3
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x3
Installing executable dist/build/x4/x4 to /tmp/cabal-dev-huh/cabal-dev//bin/x4
/usr/bin/strip /tmp/cabal-dev-huh/cabal-dev//bin/x4

Error when building cabal-install with cabal-dev

Here's my terminal session:

$ darcs get http://darcs.haskell.org/cabal 
This is the Cabal HEAD branch. If you're looking for one of the others
like the stable 1.10 branch, see http://darcs.haskell.org/cabal-branches/
**********************
Copying patches, to get lazy repository hit ctrl-C...
Finished getting.                         
$ cd cabal/cabal-install
$ cabal-dev add-source ../cabal
Building source dist at ../cabal for Cabal-1.11.0
Resolving dependencies...
[ 1 of 62] Compiling Distribution.Compat.Exception (Distribution/Compat/Exception.hs, dist/setup/Distribution/Compat/Exception.o )
[...]
[62 of 62] Compiling Main             ( Setup.hs, dist/setup/Main.o )
Linking ./dist/setup/setup ...
Configuring Cabal-1.11.0...
Building source dist for Cabal-1.11.0...
Preprocessing library Cabal-1.11.0...
setup: can't find source for Paths_Cabal in .,
dist/src/sdist.-6009/Cabal-1.11.0/dist/build/autogen

I'm then able to do cabal-dev install, but the Cabal package is absent from the local database:

$ ls cabal-dev/packages-7.0.3.conf 
HTTP-4000.1.1-7307331a7f052a69bdd620a27081320d.conf    
package.cache
zlib-0.5.3.1-5fbdf714525b76e0e601c2ffb25f2044.conf
mtl-2.0.1.0-9763a8821c812a910d327bad2c0d23b2.conf
parsec-3.1.1-9ad7689ce68f46e0751207509e882c5b.conf
network-2.3.0.4-3ac6bb38978a0758e807f7956decb2f2.conf
transformers-0.2.2.0-a8a2dbba7d96131db605cf631ea0c8c4.conf

can't build on ghc 7.2.1

seems to be a cabal constraint problem

cabal install cabal-dev
Resolving dependencies...
cabal: cannot configure unix-2.4.2.0. It requires base >=4.2 && <4.4
For the dependency on base >=4.2 && <4.4 there are these packages:
base-4.2.0.0, base-4.2.0.1, base-4.2.0.2, base-4.3.0.0 and base-4.3.1.0.
However none of them are available.
base-4.2.0.0 was excluded because base-4.4.0.0 was selected instead
base-4.2.0.0 was excluded because of the top level dependency base -any
base-4.2.0.1 was excluded because base-4.4.0.0 was selected instead
base-4.2.0.1 was excluded because of the top level dependency base -any
base-4.2.0.2 was excluded because base-4.4.0.0 was selected instead
base-4.2.0.2 was excluded because of the top level dependency base -any
base-4.3.0.0 was excluded because base-4.4.0.0 was selected instead
base-4.3.0.0 was excluded because of the top level dependency base -any
base-4.3.1.0 was excluded because base-4.4.0.0 was selected instead
base-4.3.1.0 was excluded because of the top level dependency base -any

-f-flagName fails, but --flags="-flagName" works

Reproduction:

$ cabal unpack darcs
$ cd darcs-...
$ cabal-dev install -f-curl

vs.
$ cabal-dev install --flags="-curl"

The -f-curl flag doesn't prevent darcs from building with curl, but using --flags="-curl" does.

Possible issue with shared libraries

Henning Thielemann reported the following failure via e-mail:

Can cabal-dev cope with shared libraries?

$ cabal-dev install --enable-shared --constraint="QuickCheck>=2" non-negative
Resolving dependencies...
Configuring non-negative-0.1...
Preprocessing library non-negative-0.1...
Preprocessing executables for non-negative-0.1...
Building non-negative-0.1...
[1 of 4] Compiling Numeric.NonNegative.Class ( src/Numeric/NonNegative/Class.hs, dist/build/Numeric/NonNegative/Class.o )
[2 of 4] Compiling Numeric.NonNegative.Wrapper ( src/Numeric/NonNegative/Wrapper.hs, dist/build/Numeric/NonNegative/Wrapper.o )
[3 of 4] Compiling Numeric.NonNegative.ChunkyPrivate ( src/Numeric/NonNegative/ChunkyPrivate.hs, dist/build/Numeric/NonNegative/ChunkyPrivate.o )
[4 of 4] Compiling Numeric.NonNegative.Chunky ( src/Numeric/NonNegative/Chunky.hs, dist/build/Numeric/NonNegative/Chunky.o )
[1 of 4] Compiling Numeric.NonNegative.Class ( src/Numeric/NonNegative/Class.hs, dist/build/Numeric/NonNegative/Class.dyn_o )
[2 of 4] Compiling Numeric.NonNegative.Wrapper ( src/Numeric/NonNegative/Wrapper.hs, dist/build/Numeric/NonNegative/Wrapper.dyn_o )
[3 of 4] Compiling Numeric.NonNegative.ChunkyPrivate ( src/Numeric/NonNegative/ChunkyPrivate.hs, dist/build/Numeric/NonNegative/ChunkyPrivate.dyn_o )
[4 of 4] Compiling Numeric.NonNegative.Chunky ( src/Numeric/NonNegative/Chunky.hs, dist/build/Numeric/NonNegative/Chunky.dyn_o )
<command line>: cannot satisfy -package-id QuickCheck-2.4.0.1-d485bec543ae623a1e89f94a89fbec36
    (use -v for more information)
cabal: Error: some packages failed to install:
non-negative-0.1 failed during the building phase. The exception was:
ExitFailure 1

If I omit the --enable-shared flag, then the package can be built. I have installed QuickCheck with --enable-shared.

Provide some mechanism for refreshing changing projects

This issue is similar to issue 36. The problem is that I'll be working on something in say the snap package that involves unreleased code from the rest of the snap framework. In the snap project directory, I will have done add-source for local copies of snap-core, snap-server, heist, etc. Then I'll modify something in one of those projects and I want the changes to show up when I build the snap project. I don't want to delete the whole sandbox, because then the build will take forever. My usual practice is to dig inside the sandbox directory, specifically delete files having to do with the changed project, then issue add-source for that project again.

The reason I'm opening a new issue instead of just commenting on issue 36 is because being warned about it isn't really a big problem for me. I usually know when something changed, and I want to refresh it. Ideally the add-source action would just detect changes and do the right thing. I realize that could be difficult. A simpler solution that would be completely acceptable would be to add a "-f" flag to the add-source action that would force the reload of said project.

This is a big issue for me. I run into this all the time with the Snap framework and other proprietary projects I'm involved with that use multiple projects not on hackage. Improving the workflow here would be a big win.

added sources not used for configure

Trying to add a source and then run configure fails:

$ ls
foo something
$ cd foo
$ cabal-dev add-source ../something
$ cabal-dev configure
Resolving dependencies...
Configure foo-1.0...
setup: At least the following dependencies are missing:
something -any
$

But if I skip the configure phase and jump to install, it seems to work:

$ cabal-dev install
Resolving dependencies...
Configuring something-1.3...
Preprocessing library something-1.3...
Preprocessing executables for something-1.3...
Building something-1.3...
...

cabal-install init does not recognize --verbose

Trying to use cabal-dev init produces the error

unrecognized option `--verbose=1'

cabal-dev -v init shows this comes from cabal-install:

/usr/local/bin/ghc-pkg --version
Using ghc-pkg 7.0.3
/home/brandon/.cabal/bin/cabal --numeric-version
/home/brandon/.cabal/bin/cabal --version
/home/brandon/.cabal/bin/cabal --config-file=/home/brandon/code/test/cabal-dev/cabal.config --verbose=2 init
unrecognized option `--verbose=2'

The only documentation I've found on required versions is issue #3, which suggests Cabal-1.8.0.6
and cabal-install-0.8.2 is sufficient. This is exactly what I'm running:

cabal-install -V

cabal-install version 0.8.2
using version 1.8.0.6 of the Cabal library

ghc-7.4.1 installs Cabal-1.14.0 cabal-dev-0.9 depends on Cabal < 1.11 and HTTP-4000.2.1

ghc-7.4.1 installs Cabal-1.14.0
cabal-dev-0.9 depends on Cabal < 1.11
cabal install cabal-dev cannot satisfy a dependency on HTTP-4000.2.1 because HTTP-4000.2.1 depends on base < 4..5 and ghc-7.4.1 installs base-4.5.

Make 'buildopts' command emit inline-friendly GHC options

What appears to be happening is that git-annex is using a ghc (through a Makefile) to build some haskell files. I don't know how common this is, but it seems like cabal-dev cannot handle this case easily.

cabal-dev provides a command called 'buildopts' that could do what you want without having to add an extra 'ghc' command, but it turns out that 'buildopts' isn't as useful as it could be because its output cannot be directly embedded in a GHC command like:

ghc `cabal-dev buildopts` Foo.hs

This is due to several reasons:

• it emits informative lines like == GHC Arguments: Start ==;
• it emits the actual names of the files that cabal-dev would compile if it built your package;
• it emits all of the GHC options repeatedly for all of the things it would compile if it built your package.

I've never had occasion to use 'buildopts' in its current form, but I can see it being useful if it were possible to construct GHC commands such as the one you are trying to run. I could see people writing some shell commands to munge the output of the current command to get into a form for this purpose, but I could also see everyone having to write those same commands and I'd rather avoid that.

What do folks think about changing 'buildopts' to 1) only emit the options necessary to give GHC the right context, 2) only emit them once, and 3) suppress the informative lines? Is this feasible?

Path parsing changed in recent cabal/cabal-install's

The cabal path parsing changed in recent Cabal or cabal-installs, so quoted paths are not parsed as they were previously. Attempting to use cabal-dev on an existing sandbox, with a newer cabal-install on the path (built with Cabal-1.10) results in errors like this:

$ cabal-dev install
Resolving dependencies...
Configuring VersionSpaces-0.0...
cabal: expected an absolute directory name for --prefix:
"/home/creswick/development/havsa/cabal-dev/"
cabal: Error: some packages failed to install:
VersionSpaces-0.0 failed during the configure step. The exception was:
ExitFailure 1
$ cabal --version
cabal-install version 0.9.5
using version 1.10.0.0 of the Cabal library 

The error is slightly different if there is no cabal-dev sandbox:
$ cabal-dev install
Resolving dependencies...
Configuring mtl-1.1.1.1...
cabal: expected an absolute directory name for --prefix:
"/home/creswick/development/havsa/cabal-dev/"
cabal: Error: some packages failed to install:
VersionSpaces-0.0 depends on mtl-1.1.1.1 which failed to install.
logict-0.4.1 depends on mtl-1.1.1.1 which failed to install.
mtl-1.1.1.1 failed during the configure step. The exception was:
ExitFailure 1
(although, the difference is minor -- it fails sooner.)

John Millikin suggested this fix:
I ended up fixing this by changing line 137 of RewriteCabalConfig.hs
from @eExpand = fmap show . ePath@ to @eExpand = ePath@, matching the
definition on line 118.
This breaks some behavior with older versions of Cabal/cabal-install (and triggers a test failure), so it would be nice to find a more general solution.

Does not support build-tools like alex and happy if not installed external to cabal-dev

I tried to use cabal-dev to build a package which depends on alex and happy. At first, I had alex and happy in the build-tools field of the project's cabal file, but not in build-depends. This caused the build of that project to simply fail to find alex and happy. I then added alex and happy to build-depends. cabal-dev then built and installed alex and happy into the cabal-dev directory (they appear in cabal-dev/bin), but then when it went to build the package needing them it said:

cabal: At least the following dependencies are missing:
alex ==3.0.1, happy ==1.18.6

Those versions precisely match the versions cabal-dev had just installed.

hard to select compiler version

I have installed in /usr both ghc-6.12.3 and ghc-7.0.3, and the default ghc is ghc-7.0.3

running
cabal-dev install mypackage --with-compiler=/usr/local/bin/ghc-6.12.3
installs the package in cabal-dev/packages-7.0.3.conf despite of the fact that I'm using 6.12.3

The workaround is to invoke:
cabal-dev install mypackage --with-compiler=/usr/local/bin/ghc-6.12.3 --package-db=pwd/cabal-dev/packages-6.12.3.conf

Ideally, packages of different compiler versions should not be so easy to mix.

Dependency check problem

I am getting the a dependency problem installing yesod

cabal-dev install yesod

Resolving dependencies...
cabal.exe: cannot configure yaml-0.5.2. It requires conduit ==0.2.*
For the dependency on conduit ==0.2.* there are these packages: conduit-0.2.0.
However none of them are available.
conduit-0.2.0 was excluded because data-object-yaml-0.3.4.1 requires conduit

=0.0 && <0.2

However I have manually installed yaml-0.5.2 and data-object-yaml-0.3.4.1 into the sandbox.
I guess the cabal dependency check is being used, so that the checker is unaware that the packages have already been installed in the sandbox.
Is it possible to deal with this problem?

Robert

cabal-dev does not pull tools

cabal-dev does not pull tools (like happy or c2hs) and they have to be installed manually. Since the information is present in .cabal files it should work correctly (it might be bug of cabal-install however).

Support 'test' as a top-level command.

We should support 'test' if the underlying cabal-install supports it.

$ cabal-dev test
Unknown command: "test"

Usage: cabal-dev <command>

Should read location of local repo cache from ~/.cabal/config

The Haskell Platform 2011.2 puts the local repo cache in a different location than previous versions. It is now in ~/Library/Haskell/repo-cache instead of ~/.cabal/packages.

The change is reflected in the ~/.cabal/config file

cabal-dev should read the ~/.cabal/config file to find the location instead of assuming ~/.cabal/packages

(edit: updated to say repo cache instead of package database. - ERC)

cabal-dev asking for password

For reasons I cannot fathom, cabal-dev is asking for my password when installing a sandbox package. To reproduce:

$ mkdir test && cd test 
$ git clone https://github.com/HeinrichApfelmus/reactive-banana
Cloning into reactive-banana...
remote: Counting objects: 641, done.
remote: Compressing objects: 100% (406/406), done.
remote: Total 641 (delta 346), reused 498 (delta 203)
Receiving objects: 100% (641/641), 169.82 KiB | 158 KiB/s, done.
Resolving deltas: 100% (346/346), done.
$ cd reactive-banana/
$ chmod -R u+rw .
$ cabal-dev install reactive-banana/
Resolving dependencies...
Configuring reactive-banana-0.4.2.0...
Preprocessing library reactive-banana-0.4.2.0...
Building reactive-banana-0.4.2.0...
[1 of 7] Compiling Reactive.Banana.Vault ( src/Reactive/Banana/Vault.hs, dist/build/Reactive/Banana/Vault.o )
[2 of 7] Compiling Reactive.Banana.Model ( src/Reactive/Banana/Model.hs, dist/build/Reactive/Banana/Model.o )
[3 of 7] Compiling Reactive.Banana.PushIO ( src/Reactive/Banana/PushIO.hs, dist/build/Reactive/Banana/PushIO.o )
[4 of 7] Compiling Reactive.Banana.Implementation ( src/Reactive/Banana/Implementation.hs, dist/build/Reactive/Banana/Implementation.o )
[5 of 7] Compiling Reactive.Banana.Tests ( src/Reactive/Banana/Tests.hs, dist/build/Reactive/Banana/Tests.o )
[6 of 7] Compiling Reactive.Banana.Incremental ( src/Reactive/Banana/Incremental.hs, dist/build/Reactive/Banana/Incremental.o )
[7 of 7] Compiling Reactive.Banana  ( src/Reactive/Banana.hs, dist/build/Reactive/Banana.o )
[1 of 7] Compiling Reactive.Banana.Vault ( src/Reactive/Banana/Vault.hs, dist/build/Reactive/Banana/Vault.p_o )
[2 of 7] Compiling Reactive.Banana.Model ( src/Reactive/Banana/Model.hs, dist/build/Reactive/Banana/Model.p_o )
[3 of 7] Compiling Reactive.Banana.PushIO ( src/Reactive/Banana/PushIO.hs, dist/build/Reactive/Banana/PushIO.p_o )
[4 of 7] Compiling Reactive.Banana.Implementation ( src/Reactive/Banana/Implementation.hs, dist/build/Reactive/Banana/Implementation.p_o )
[5 of 7] Compiling Reactive.Banana.Tests ( src/Reactive/Banana/Tests.hs, dist/build/Reactive/Banana/Tests.p_o )
[6 of 7] Compiling Reactive.Banana.Incremental ( src/Reactive/Banana/Incremental.hs, dist/build/Reactive/Banana/Incremental.p_o )
[7 of 7] Compiling Reactive.Banana  ( src/Reactive/Banana.hs, dist/build/Reactive/Banana.p_o )
Registering reactive-banana-0.4.2.0...
Running Haddock for reactive-banana-0.4.2.0...
Preprocessing library reactive-banana-0.4.2.0...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: ffi-1.0, rts-1.0
haddock coverage for dist/build/tmp2944/src/Reactive/Banana/Vault.hs:     6/8  75%
Warning: Reactive.Banana.Model: Instances of type and data families are not yet supported. Instances of the following families will be filtered out:
  Event, Behavior
haddock coverage for dist/build/tmp2944/src/Reactive/Banana/Model.hs:   13/17  76%
Warning: Reactive.Banana.PushIO: Instances of type and data families are not yet supported. Instances of the following families will be filtered out:
  Event, Behavior, Behavior, Event
haddock coverage for dist/build/tmp2944/src/Reactive/Banana/PushIO.hs:    1/55   2%
haddock coverage for dist/build/tmp2944/src/Reactive/Banana/Implementation.hs:   24/25  96%
haddock coverage for dist/build/tmp2944/src/Reactive/Banana/Tests.hs:     0/5   0%
haddock coverage for dist/build/tmp2944/src/Reactive/Banana/Incremental.hs:   10/11  91%
haddock coverage for dist/build/tmp2944/src/Reactive/Banana.hs:     3/7  43%
Documentation created: dist/doc/html/reactive-banana/index.html
Password:
Sorry, try again.
Password:
Sorry, try again.
Password:
Sorry, try again.
sudo: 3 incorrect password attempts
cabal: Error: some packages failed to install:
reactive-banana-0.4.2.0 failed during the final install step. The exception
was:
ExitFailure 1

(At the time of this writing, the latest commit to the reactive-banana repo is fa91fc7cd14bdd4d40322c919548cfa4f4908076 )

I am of the opinion that cabal-dev has no business knowing my password, what's going on?

$ cabal-dev --version
cabal-dev 0.8
built with Cabal 1.10.1.0

add-source fails due to invalid cross-device link

Hello,

I've a cabal-dev project on a filesystem on an encrypted partition. Now I want to cabal-dev add-source a project from a filesystem on my unencrypted partition. However I get the following error:

unsupported operation (Invalid cross-device link)

I guess cabal-dev tries to make a hard-link from my encrypted partition to my unencrypted partition which is invalid.

Is it possible to create symbolic links instead?

support new cabal test workflow

The following workflow needs to be supported:

cabal configure --enable-tests
cabal build
cabal test

What happens when I try:

~/proj/hs/y/me/persistent mongoDB5+!? cabal-dev configure --enable-tests   
Resolving dependencies...
Configuring persistent-0.4.0.1...
cabal: At least the following dependencies are missing:
persistent-mongoDB -any,
persistent-postgresql -any,
persistent-sqlite -any
~/proj/hs/y/me/persistent mongoDB5+!? cabal-dev install-deps  --enable-tests              
No dependencies need to be installed
~/proj/hs/y/me/persistent mongoDB5+!? cabal-dev build                      
cabal: Run the 'configure' command first.

cabal-dev built by one user can't be run by another

It look like cabal-dev hard-codes some paths into itself, so that if user foo builds it, and user bar runs the version built by foo, they'll fail. For instance, here's an attempt by the jenkins user to run a cabal-dev built by the ec2-user user:

[workspace] $ /bin/sh -xe /tmp/hudson8441083209330691554.sh
+ cabal-dev install
cabal-dev: /home/ec2-user/.cabal/share/cabal-dev-0.7.4.0/admin/00-index.tar: copyFile: permission denied (Permission denied)

It's not obvious how to override this :-(

cabal-dev ghci broken in 0.9

After cabal-dev install-deps in 0.8 cabal-dev ghci worked properly, in 0.9 it is broken. It says:

pwd:proj gracjan$ cabal-dev ghci
cabal-dev: user error (cabal: ghc-pkg: /Users/gracjan/proj/cabal-dev/packages-6.12.3.conf:
openFile: does not exist (No such file or directory)
)

Proper directory listed should be:

/Users/gracjan/Code/proj/cabal-dev/packages-6.12.3.conf

Note 'Code' part.

"dist" directory should be moved to the sandbox

Due to stale "dist" directories causing problems with cabal builds after toolchain upgrades, the "dist" directory for each package should be located within the sandbox.

cabal file updates needed

The following enhancements to the cabal file need to be made:

• I often read the package description on Hackage to find out what a package is all about. The package description for cabal-dev, while not misleading, does not give developers sufficient context to know where to start. A couple more examples and/or links to documentation would be a good start.
• The cabal file should also be updated to fill in at least the bug-reports field to point to this bug tracker.
• The copyright needs to be updated to 2011.

cabal-dev can't distinguish .hi files

My install of cabal-dev on OS X (0.8 of hackage and d876a99) doesn't seem to include the module-specific path component when it's deciding where to place .hi files within ./cabal-dev/

Thus I get lots problems when installing multiple modules which have modules with the same name. For instance:

Something is amiss; requested module  MonadCatchIO-mtl-0.3.0.4:Control.Monad.CatchIO differs from name found in the 
interface file MonadCatchIO-transformers-0.2.2.2:Control.Monad.CatchIO

with a reference to .../cabal-dev//lib/Control/Monad/CatchIO.hi.

Respecting global packages

I've got a project that indirectly depends on template haskell. My dev environment has GHC 7.4.2 which must have template-haskell >= 2.6. My target environment has GHC 7.0.4, which must have template-haskell 2.5. When I try to compile in production, cabal-dev tries to go fetch the latest template-haskell (2.7) which fails to install on the old compiler. As far as I know I can't preprocess the cabal file with GHC version. Is there any way for cabal-dev to link against the global packages included with the compiler to prevent this mayhem, or is there an alternative that I'm not seeing?

avoid need for cabal dev install --reinstall --force-reinstall

I think Cabal 1.14 is a lot more conservative about reinstalling packages. You now get a warning which will hopefully prevent people from as easily landing themselves the usual weird reinstall/clobber dependency hell.

That's great, but if you're using cabal-dev, running something like cabal-dev install . ./foo ./bar gives me an annoying warning, and I instead of have to type cabal-dev install . ./foo ./bar --reinstall --force-reinstall

I most likely misunderstand the issue, but in case I don't, it seems like cabal-dev should compensate for Cabal's (good, desirable) extra conservatism by letting users clobber their local cabal-devs in the old way.