- cabal-devel - Haskell.org

Re: patch applied (packages/Cabal): Fix the base-upper-bound Cabal check error
by Duncan Coutts 12 Aug '09

12 Aug '09

On Tue, 2009-08-11 at 15:34 -0700, Ian Lynagh wrote: > Tue Aug 11 13:44:55 PDT 2009 Ian Lynagh <igloo(a)earth.li> > * Fix the base-upper-bound Cabal check error > > M ./Distribution/PackageDescription/Check.hs -7 +11 This should be pushed to the Cabal HEAD repo before going into ghc's Cabal branch. Duncan

2 1

patch applied (cabal): Fix the base-upper-bound Cabal check error
by Ian Lynagh 12 Aug '09

12 Aug '09

Tue Aug 11 13:44:55 PDT 2009 Ian Lynagh <igloo(a)earth.li> * Fix the base-upper-bound Cabal check error M ./Distribution/PackageDescription/Check.hs -7 +11 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090811204455-3fd76-53a4a8b4…

1 0

Add InstalledPackageIds, take 3
by Simon Marlow 10 Aug '09

10 Aug '09

Duncan asked me to split up the patch to make it easier to digest. So here it is, in 10 pieces (one of which is just a refactoring).

2 1

[Hackage] #574: Cabal doesn't respect ghc installation path
by Hackage 10 Aug '09

10 Aug '09

#574: Cabal doesn't respect ghc installation path ----------------------------+----------------------------------------------- Reporter: count0 | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I've installed ghc (version 1.6.0.1 - 1.6.0.3) in d:\Haskell\ghc, so I expect that Cabal will install a new package in there, but Cabal always installs a package in "C:\Program Files\Haskell". It seems Cabal doesn't detect where ghc is installed. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/574> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

wxhaskell installation issue
by Brian Lewis 10 Aug '09

10 Aug '09

Could a cabal developer please weigh in on this thread? http://article.gmane.org/gmane.comp.lang.haskell.wxhaskell.general/722 The summary is that the wxhaskell cabal package tries to register itself with ghc-pkg. I think this is fundamentally busted behavior, but I'd appreciate hearing opinions from experts. Thanks.

2 1

[Hackage] #481: License compatibility check
by Hackage 05 Aug '09

05 Aug '09

#481: License compatibility check ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- It would be nice if Cabal could report license compatibility problems - e.g.: * Trying to build a BSD3-licensed package that depends on a GPL package * Trying to build a proprietary-licensed package that depends on a GPL package -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/481> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #411: Command to install dependencies of a package.
by Hackage 05 Aug '09

05 Aug '09

#411: Command to install dependencies of a package. ---------------------------------+------------------------------------------ Reporter: mornfall | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Something like cabal install-deps or install --deps-only or such. We spoke about this with Duncan and this is the proposed solution to my use-case: I have a project that basically consists of a simple shebang haskell script (go.hs), which happens to have somewhat obscure dependencies. I am not interested in building a binary out of this script, nor installing it: but I'd like to use cabal to track and automatically install the dependencies for it. Hence, I would provide a cabal file, whose main purpose would be for people to run "cabal install-deps", which would enable them to run ./go.hs directly... Hopefully it is clear what I mean here... Don't hesitate to prod me if you have better suggestions, or, questions... -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/411> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #573: package page could mention used language extensions
by Hackage 04 Aug '09

04 Aug '09

#573: package page could mention used language extensions ----------------------------+----------------------------------------------- Reporter: explicitcall | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: miscellaneous | Version: 1.6.0.1 Severity: minor | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- It would be very convenient to see what language extensions a given package uses at its own hackageDB page. This information could be gathered from LANGUAGE pragmas put in distinct files or from GHC's -X options specified in .cabal file. Complete list of used extensions gives a possibility to see how the package can be used, as it's common practice to choose library judging by such features as portability and usability. For example, new library users could see how they possibly could understand code and documentation, as usage of extensions requires some better knowledge of the language. At the same time, power users could seek appropriate libraries which integrate properly with the list of language extensions they already use. The list of used extensions could be produced by hackageDB scripts every time the package is uploaded to hackageDB, or it can be generated by `cabal sdist` when a source distribution file is generated. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/573> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #569: strings with more than one URL in them mis-parsed
by Hackage 01 Aug '09

01 Aug '09

#569: strings with more than one URL in them mis-parsed ----------------------------+----------------------------------------------- Reporter: EricKow | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- It appears that strings with more than one URL in them are parsed incorrectly. For example, {{{ See <http://www.mediawiki.org/wiki/API> and <http://haskell.forkio.com/> }}} gets treated as though there was only one URL. I get the impression that there's some kind of greedy matching going on, like a "<.*>" in regexp terms. This manifests as funny looking output on hackage, eg. http://hackage.haskell.org/package/mediawiki -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/569> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #571: bad error message: "There is no installed version of base"
by Hackage 01 Aug '09

01 Aug '09

#571: bad error message: "There is no installed version of base" ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: low | Milestone: Component: cabal-install tool | Version: HEAD Severity: minor | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Here's a trimmed down version of the problem, demonstrated in a shell session: {{{ # ls Setup.lhs u.cabal # cat u.cabal cabal-version: >= 1.2 build-type: Simple name: u version: 0.0 library # cabal install Resolving dependencies... cabal: There is no installed version of base }}} What is wrong? Building and installing the package with Cabal (using Setup.lhs) worked fine. And according to ghc-pkg, base was installed. After a while I figured out a solution - apparently cabal-install expects the package to depend on base: {{{ # echo ' build-depends: base >= 4 && < 5' >> u.cabal # cabal install Resolving dependencies... Configuring u-0.0... Preprocessing library u-0.0... Building u-0.0... Registering u-0.0... Installing library in /opt/ghc-6.10.4/lib/u-0.0/ghc-6.10.4 Registering u-0.0... # }}} Is there a good reason for this behaviour? (Setting low priority because the vast majority of packages depends on base anyway.) Versions: {{{ cabal-install version 0.7 -- darcs head using version 1.7.3 of the Cabal library -- ghc's version }}} -- int-e -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/571> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0