December 2010 - cabal-devel

darcs patch: Add a new checkout Command (and 1 more)
by Joachim Breitner 21 Jul '13

21 Jul '13

Hi, the small feature implemented by the attached patches could make it more convenient for people to quickly and easily contribute to hackage packages. Do you want me to open a ticket for this or can you appl yit right away? Thanks, Joachim 2 patches for repository http://darcs.haskell.org/cabal-install: Sun Nov 7 12:35:32 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Add a new checkout Command Given a package name, this uses the SourceRepo field of the newest versionf of that pacakge to figure out the repository location and calls the right VCS invocation. Sun Nov 7 12:43:35 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Add a --dry-run flag to cabal checkout

2 3

hackage-server: index format
by Antoine Latter 21 Dec '12

21 Dec '12

Hi folks, The index tar-ball on Hackage has an odd naming convention. Package descriptions are given paths of the form: ./$pkg/$version/$pkg.cabal including the leading "./". I'm guessing that this is done as a method of distinguishing non-package meta-data. Is this a convention we need to preserve? Thanks, Antoine

6 12

[Hackage] #777: cabal install {hledger, others} ExitFailure 11
by Hackage 15 Aug '12

15 Aug '12

#777: cabal install {hledger, others} ExitFailure 11 ---------------------------------+------------------------------------------ Reporter: philips | Owner: Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.8 Component: cabal-install tool | Version: 1.8.0.2 Severity: normal | Keywords: ExitFailure Difficulty: unknown | Ghcversion: Platform: Linux | ---------------------------------+------------------------------------------ I am getting ExitFailure 11 when trying to install hledger on Debian and openSUSE. I reported this to the hledger author, Simon, and he said he is experiencing this on his machines too and for other packages, not just hledger. Log file attached. Summary below: {{{ ledger:~/ $ cabal install -v3 hledger Lots of debug output (see attached)... hledger-0.13 failed during the configure step. The exception was: ExitFailure 11 ledger:~/ $ cabal --version cabal-install version 0.8.2 using version 1.8.0.2 of the Cabal library ledger:~/ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/777> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

[Hackage] #780: Simpler support for isolated/sandboxed builds
by Hackage 25 Apr '12

25 Apr '12

#780: Simpler support for isolated/sandboxed builds ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Cabal/cabal-install allows setting the install prefix and the package database. Together these allow creating isolated builds. This is clearly not sufficiently easy to use as there are now two projects that provide wrappers over cabal-install to provide more direct support for this use case: * http://github.com/creswick/cabal-dev/blob/master/README.md * http://www.haskell.org/haskellwiki/Capri The task is to investigate what user behaviour is desired and to integrate this in the best way with Cabal/cabal-install. This is probably related to: * ticket #556 about local config files (e.g. persistently setting some sandbox flag) * ticket #734 about supporting multiple local .cabal files * ticket #524 about supporting file, directory and url targets for packages and .cabal files -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/780> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #661: optionally select the oldest available dependencies rather than the newest
by Hackage 20 Apr '12

20 Apr '12

#661: optionally select the oldest available dependencies rather than the newest ----------------------------+----------------------------------------------- Reporter: benmachine | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When developing a package, you want to specify as wide a range of build- depends as possible, but it's often quite tedious to keep checking if your latest development effort hasn't made your package incompatible with some ancient version of a library you use. In view of this I think it would be helpful to have an option that asks cabal configure to pick the oldest possible version of each dependency, so you could quickly and easily ensure that at least the two endpoints are covered. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/661> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #695: cabal install world always reinstalls programs
by Hackage 16 Apr '12

16 Apr '12

#695: cabal install world always reinstalls programs ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ cabal-install does not currently track the installed state of programs. It does now list them in the world file however. This leads to it always wanting to reinstall programs. Probably we do want to keep the programs in the world file, since we hopefully will track programs better in future. The temporary hack would be to filter out packages that have no lib when retrieving packages from the world file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/695> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #694: mention --constraint flag in error essage when dep planning fails
by Hackage 16 Apr '12

16 Apr '12

#694: mention --constraint flag in error essage when dep planning fails ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Dependency planning problems can often be solved by running with --dry-run -v, seeing what the planner is selecting and forcing it to make different choices using the --constraint flag. When dependency planning fails with particular kinds of constraint problem, it may be useful to users to mention this. We should check if this advice applies to all cases where the dep planner fails, or if its only appropriate for certain classes of failure. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/694> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #753: cabal executable chooses different versions of libraries than cabal library
by Hackage 10 Apr '12

10 Apr '12

#753: cabal executable chooses different versions of libraries than cabal library ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Hi, cabal-install version 0.8.2 using version 1.8.0.2 of the Cabal library This bug was originally reported by a Debian user. the `cabal' executable, when run on the attached sample library, chooses base 3.0.3.2: $ cabal -v configure [...] Configuring foobar-0.0... Dependency base ==3.0.3.2: using base-3.0.3.2 [...] whereas, the library (via Setup.hs) correctly gets base 4.2.0.0, probably due to ghc's hiding of the earlier version $ runhaskell Setup.hs -v configure Configuring foobar-0.0... Dependency base -any: using base-4.2.0.0 [...] cabal-install should probably perform the same hiding that ghc does. Cheers, Iain -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/753> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #762: cabal-install failed to resolve dependencies
by Hackage 08 Apr '12

08 Apr '12

#762: cabal-install failed to resolve dependencies ---------------------------------+------------------------------------------ Reporter: james_m_chapman | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I tried to update my installation of the development version of Agda. I did a darcs pull from the repo (darcs get --lazy http://code.haskell.org/Agda) and then tried to build it: $ darcs pull $ cabal update $ cabal clean $ cabal install I get the following error: "Resolving dependencies... cabal: cannot configure haskeline-0.6.2.2. It requires mtl ==1.1.* For the dependency on mtl ==1.1.* there are these packages: mtl-1.1.0.0, mtl-1.1.0.1, mtl-1.1.0.2 and mtl-1.1.1.0. However none of them are available. mtl-1.1.0.0 was excluded because Agda-2.2.9 requires mtl ==2.0.* mtl-1.1.0.1 was excluded because Agda-2.2.9 requires mtl ==2.0.* mtl-1.1.0.2 was excluded because Agda-2.2.9 requires mtl ==2.0.* mtl-1.1.1.0 was excluded because Agda-2.2.9 requires mtl ==2.0.*" Agda's .cabal file is here http://code.haskell.org/Agda/Agda.cabal and contains the build-depends line haskeline >= 0.3 && < 0.7 The solution is to upgrade haskeline to the latest version by running: $ cabal install haskeline Should cabal-install have been able to work this out itself? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/762> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #782: When building a plan, use installed package dependencies in preference to those from Hackage
by Hackage 08 Apr '12

08 Apr '12

#782: When building a plan, use installed package dependencies in preference to those from Hackage ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I was installing a package, let us call it foo. This package depended on a package foo', which in turn depended on bar, which in turn depended on baz < 0.3, but baz 0.3 was the default that came with the newer version of GHC I had just installed. Thus, I cabal-unpacked bar and bumped the baz dependency to < 0.4, **without changing the baz version number** since this was just a private change. This built and installed just fine with the new baz. I then went back to cabal install foo. I expected that cabal-install would just install foo' and then foo in that order. Instead, it tried to install baz 0.2, then bar, then foo', then foo. This seems stupid because I already had a perfectly acceptable bar installed. Why didn't Cabal just reuse that? It seems as if it is resolving dependencies by looking at the dependency information for bar **from the Hackage database** rather than the dependencies **from the installed bar**. The workaround is to go back to the unpacked bar and bump the version number, then reinstall it. Now when you install foo the installed baz is used as expected. It would be cool if this worked as expected without bumping the version number, because having to bump the version number even if not making a Hackage release is tiresome. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/782> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3