creswick / cabal-dev Goto Github PK

View Code? Open in Web Editor NEW

150.0 150.0 24.0 496 KB

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

License: BSD 3-Clause "New" or "Revised" License

Haskell 99.89% Shell 0.11%

cabal-dev's People

Contributors

Stargazers

Watchers

Forkers

aleator juhp dmwit bos mvv konn coreyoconnor bgamari elliottt dagit isturdy sol ppetr carlssonia aristidb adinapoli etrepum hdgarrood domdere johnlato vitekyang bergmark silkapp luckypoem

cabal-dev's Issues

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.

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

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 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.

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

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.

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.

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.

Automate uninstallation of packages

Please.

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...
...

-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.

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?

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.

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.

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.

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

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 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

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.

"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.

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)
)

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 :-(

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?

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.

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?"

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.

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.

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.

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.

`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...

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

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

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!!!!!!

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:

cabal install yesod-platform
Make sure yesod is in your path
yesod init -- call the project "cabaldev-bugtest"
cd cabaldev-bugtest
cabal --dry-run install
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

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.

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

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).

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.

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.

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

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)

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>

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?

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-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.

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

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?

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.

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.

creswick / cabal-dev Goto Github PK

cabal-dev's People

Contributors

Stargazers

Watchers

Forkers

cabal-dev's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs