March 2011 - cabal-devel

[Hackage] #676: bash-completion gets confused by alias for rm
by Hackage 05 Jan '12

05 Jan '12

#676: bash-completion gets confused by alias for rm ---------------------------------+------------------------------------------ Reporter: benmachine | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: minor | Keywords: Difficulty: unknown | Ghcversion: 6.12.1 Platform: Linux | ---------------------------------+------------------------------------------ I have an alias for rm defined so that it is by default verbose (alias rm='rm -v' in my bashrc). When I do cabal install has<tab> I get something like: [ben@euler ~]$ cabal install hasbash: bad substitution: no closing "`" in `/tmp/cabal_completion.tD2o8O' It turns out that rm is helpfully going: removed `/tmp/cabal_completion.hb1zbc' and then cabal is trying to use this as part of the completion command - choking on the ` because bash thinks it is part of a substitution. So rm should probably explicitly discard its stdout. While I was there I noticed that "cat" is used redundantly. There's nothing really wrong with this so that part of the patch can be cut I suppose, but I thought it was neater to use bash's input redirection explicitly. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/676> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #677: Error: Couldn't read cabal file "./HDBC/2.2.5/HDBC.cabal"
by Hackage 05 Jan '12

05 Jan '12

#677: Error: Couldn't read cabal file "./HDBC/2.2.5/HDBC.cabal" ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.10.4 Platform: Linux | ---------------------------------+------------------------------------------ I recently upgraded cabal-install and started getting this error: $ cabal install HDBC Resolving dependencies... cabal: Couldn't read cabal file "./HDBC/2.2.5/HDBC.cabal" I also get the same error when I try to install one of my own packages that depends on HDBC. I tried changing my HDBC dependency to == 2.2.2 as well as >= 2.2.6, but still get the same error for version 2.2.5. I have cabal-install version 0.6.2 and Cabal version 1.6.0.3. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/677> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #674: Findable extra documentation
by Hackage 05 Jan '12

05 Jan '12

#674: Findable extra documentation ----------------------------+----------------------------------------------- Reporter: jbapple | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have a cabal package that should include extra documentation in the distribution. This documentation should not be written in Haddock. 1. There should be a field for this analogous to data-files or extra- source-files. The former is too much: the files do not need to be accessed by any Haskell runtime. The latter is not enough: it does not store the extracted files on the system on which the package is installed. 2. There should be a way for humans to find these files without loading up a GHC runtime or using Unix's "find". I suggest "cabal list" also shows, for installed packages with extra data or documentation files installed, where these files can be found. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/674> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #760: exclude all but latest documentation from search results
by Hackage 01 Dec '11

01 Dec '11

#760: exclude all but latest documentation from search results --------------------------------+------------------------------------------- Reporter: warren | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- When searching for haskell documentation on google, quite frequently the top search results are versions of the library documentation from the archives. For instance, when searching for Data.Vector, the top hit is version 0.5, whereas the latest is 0.7. Also, if the user selects the 0.7 version, it isn't obvious from the documentation that this version corresponds to the latest since it also appears in the archive (the url is http://hackage.haskell.org/packages/archive/vector/0.7/doc/html/Data- Vector.html). So I'm wondering if it might not make sense to exclude all but the latest haddock documentation from search results by augmenting the robots.txt file. It might also make sense to provide alternate urls to the latest versions of documents. E.g. Starting from the http://hackage.haskell.org/package/vector page (which is the latest version), and clicking on Data.Vector, one is taken to http://hackage.haskell.org/packages/archive/vector/0.7/doc/html/Data- Vector.html... but it might be better if this were http://hackage.haskell.org/packages/current/vector/doc/html/Data- Vector.html. This would allow for all files under /archive to be excluded. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/760> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #767: Highlighted source code on hackage.haskell.org mangles Unicode
by Hackage 09 Nov '11

09 Nov '11

#767: Highlighted source code on hackage.haskell.org mangles Unicode ----------------------------------+----------------------------------------- Reporter: andersk | Owner: Type: defect | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- On hackage.haskell.org, when you browse the source of a module that contains Unicode (e.g. [http://hackage.haskell.org/packages/archive/base- unicode-symbols/latest/doc/html/src/Data-Eq-Unicode.html Data.Eq.Unicode]), it is sent with a `Content-Type: text/html` header with no charset. There is a charset in the XML declaration `<?xml version="1.0" encoding="UTF-8"?>`, but that is ignored by Firefox because of the non-XML `Content-Type`. Therefore, the wrong encoding is detected and the Unicode symbols get mangled. Possible fixes include sending `Content-Type: text/html; charset=UTF-8`, or sending `Content-Type: application/xhtml+xml` so that the XML declaration is respected , or both (`Content-Type: application/xhtml+xml; charset=utf-8`), or adding equivalent `<meta http-equiv="Content-Type">` tags. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/767> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #821: Add support for Apache license
by Hackage 25 Oct '11

25 Oct '11

#821: Add support for Apache license ----------------------------+----------------------------------------------- Reporter: bos | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have several projects licensed under the Apache license due to upstream dependencies, but Cabal doesn't know about it. This would be good to add for e.g. license compatibility checkers (I believe Galois has such a tool). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/821> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #817: "main-is" misparsed in if/else, only by sdist
by Hackage 20 Jun '11

20 Jun '11

#817: "main-is" misparsed in if/else, only by sdist ----------------------------+----------------------------------------------- Reporter: jeffwheeler | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.0.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- An if/else block which sets the main-is value for an executable based on a flag is misparsed when running "cabal sdist" (it's parsed correctly when running "cabal install"). Upon failure, it appears that it's looking for a filename that is the two main-is options concatenated together. E.g., I get the error "cabal: HackerMain.hsMain.hs doesn't exist". The problematic bit looks like: if flag(hacking) main-is: HackerMain.hs else main-is: Main.hs My entire config can be found on hpaste: http://hpaste.org/44939/yicabal (problematic lines around 268). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/817> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #813: Cabal should warn if the Cabal-Version range is too lax
by Hackage 18 Jun '11

18 Jun '11

#813: Cabal should warn if the Cabal-Version range is too lax ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have a Cabal file that contains the line {{{ Cabal-Version: >=1.6 }}} and then a test section: {{{ Test-Suite test-mypkg }}} Cabal should issue a warning like: {{{ Test-Suite feature requires Cabal-Version: >=1.10. Your Cabal version range ">=1.6" is too lax. }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/813> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #826: "dependency conflict"
by Hackage 24 Apr '11

24 Apr '11

#826: "dependency conflict" ---------------------------------+------------------------------------------ Reporter: nue_057 | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.3 Platform: Windows | ---------------------------------+------------------------------------------ when depnedency conflict happens, I usually use ghc-pkg unregister to solove the problem, but there is another problem. when I use ghc-pkg check, it always return a lot of problems, for example: there is a conflict with bytestring-0.9.1.10 and bytestring-0.9.1.7, I unregister the version of 0.9.1.10. ghc-pkg check, the message is: there are problems in package Win32-2.2.0.2 dependency "bytestring-0.9.1.10..." the following packages are broken, either beacause they have a problem listed above, or beacause the depend on a broken package. Win32-2.2.0.2, haskell98-1.0.1.1 QuickCheck-2.4.0.1... does anyone can help me to fix these broken package? thanks in advance !! -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/826> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #815: Feature Request: Translate buildplan to makefile
by Hackage 22 Apr '11

22 Apr '11

#815: Feature Request: Translate buildplan to makefile ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: makefile, make Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- For the following reasons, I would sometimes like to be able to use GNU make as my build system, but still get cabal's excellent dependency version calculations. Here are the main situations when I wish I had make: * Whenever I want cabal to do something that is not already common practice for cabal packages, I end up having to write a bunch of code in Setup.hs, hacking hooks, and whatnot. This always feels dirty and time consuming. * Cabal doesn't yet support parallel builds. * Cabal files that list many libraries or many executables do a lot of redundant work and the user doesn't have a fine grained way to specify which executables or libraries to build without going to a lot of extra configuration in the cabal file to add flags. * All modifications to the .cabal file require a full project rebuild, even when the changes do not impact the source or build plan. * I need to introspect the build. Perhaps it's not going as planned and I want to debug it. My only recourse at the moment is --verbose=3. I find that with the current API, using make and cabal's dependency calculations are mutually exclusive. I think the happy medium here is translating the LocalBuildInfo to a makefile (or part of a makefile). Ideally this makefile could be optionally included into another makefile. The expectation would be that the generated makefile is treated as an autogenerated file (eg., not checked into source control or statically placed on hackage). Instead it's regenerated during the configure step and then cabal or the user can invoke make to run the targets. I believe this would give us parallel builds, allow us to reuse more and recompile less, and allow us to examine the build plan. And all this would be possible by leveraging the nice statically checkable, declarative package specifications we have instead of mucking about with configure scripts or trying to write an unstructured makefile from hand and getting the rules subtly wrong. I could imagine it putting us into a harmonious state where we get the best of both worlds. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/815> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5