November 2010 - cabal-devel

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

20 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 20 Dec '12

20 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] #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 09 Apr '12

09 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 07 Apr '12

07 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] #731: Custom Build-type with --package-db and --global encounters runtime error
by Hackage 28 Mar '12

28 Mar '12

#731: Custom Build-type with --package-db and --global encounters runtime error ---------------------------------+------------------------------------------ Reporter: cygnus | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.2 Platform: Linux | ---------------------------------+------------------------------------------ To reproduce: * Run `cabal init`, change `Build-type` to `Custom` (`Setup.hs` already provided by `cabal init`) * Run `ghc-pkg init db` * Run `cabal configure --package-db=./db --global` * Output: {{{ Resolving dependencies... cabal: internal error: unexpected package db stack }}} In `cabal-install-0.8.2`, this appears to be caused by the code on lines 112-114 of `Distribution.Client.Configure`: {{{ usePackageDB = if UserPackageDB `elem` packageDBs then packageDBs else packageDBs ++ [UserPackageDB] }}} in combination with the code on lines 297-306 of `Distribution.Client.SetupWrapper`: {{{ ghcPackageDbOptions :: PackageDBStack -> [String] ghcPackageDbOptions dbstack = case dbstack of (GlobalPackageDB:UserPackageDB:dbs) -> concatMap specific dbs (GlobalPackageDB:dbs) -> "-no-user-package-conf" : concatMap specific dbs _ -> ierror where specific (SpecificPackageDB db) = [ "-package-conf", db ] specific _ = ierror ierror = error "internal error: unexpected package db stack" }}} Essentially, the order of the package databases in the stack is not as expected since the list already contains a `SpecificPackageDB` when the `UserPackageDB` is appended. (Note: this applies to GHC 6.12.3 and Cabal 1.8.0.6 on my system, but I could not select those versions in the ticket properties.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/731> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #675: template-haskell cannot be upgraded (broken data-accessor-template)
by Hackage 05 Mar '12

05 Mar '12

#675: template-haskell cannot be upgraded (broken data-accessor-template) ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.1 Platform: | ---------------------------------+------------------------------------------ data-accessor-template-0.2.1.3 has flags in the cabal file on template- haskell versions, which makes it broken for cabal-install on ghc-6.12: cabal-install tries to install template-haskell-2.3, which fails (and it can't be expected to succeed because TH is integrated into ghc due to quotes) You can work around the build failure with: {{{ cabal install data-accessor-template --constraint='template-haskell >= 2.4' }}} cabal-install ought to know that template-haskell isn't something it should install (as it does with base). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/675> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #665: Confusion situation when linking ./dist/setup/setup is interrupted
by Hackage 05 Mar '12

05 Mar '12

#665: Confusion situation when linking ./dist/setup/setup is interrupted ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ If one accidentally interrupts cabal when it's linking `./dist/setup/setup` then you can end up with the file existing it not being executable. This leads to a confusing situation for the user. Running `cabal install` or `cabal configure` will fail silently. Running with -v indicates that something returns exit code 127. This corresponds to a permission error when trying to execute `./dist/setup/setup` Two improvements could be made: * Report the failure to execute `./dist/setup/setup` * If ghc is interrupted when creating `./dist/setup/setup`, cabal should delete the file, if it exists. That way, cabal will recompile on the next invocation. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/665> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2