November 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] #871: Library with test builds the test executable against the library's cabal_macros.h
by Hackage 08 Dec '11

08 Dec '11

#871: Library with test builds the test executable against the library's cabal_macros.h ----------------------------+----------------------------------------------- Reporter: AntoineLatter | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Things like 'VERSION_package' may not only be wrong, but may cause compile errors if the library doesn't include the package in question (but the test does). This is likely to come up in a MIN_VERSION_criterion or MIN_VERSION_HUnit case. This might only be a problem if the test executable is using the new "build against a compiled version of the library" technique - I haven't played around too much. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/871> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

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

02 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] #901: Allow package properties to depend on --enable-tests and --enable-benchmarks.
by Hackage 30 Nov '11

30 Nov '11

#901: Allow package properties to depend on --enable-tests and --enable- benchmarks. ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Keywords: tests, benchmarks Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- In containers, in order for tests to build we need to compile the whole library with -DTESTING. Although it is probably not The Right Design (TM), it is a simple way of exporting internals used by the tests. It would be great if the package properties could depend on whether the tests were enabled or disabled (possibly also on benchmarks), either by creating flags reflecting the {{{--enable-tests}}}, or by special syntax like {{{if enabled(tests)}}}, or anything else. Currently we have flag {{{testing}}}, so whenever we want to build the tests, we pass {{{-ftesting --enable-tests}}} to the cabal configure. But only {{{--enable-tests}}} should suffice, if the tests are meant to run automatically. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/901> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #517: make cabal install command support haddock options
by Hackage 28 Nov '11

28 Nov '11

#517: make cabal install command support haddock options ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by massysett): Oops, please ignore my last comments...perhaps the latest Cabal can do this...problem is, I can't get it installed on ghc 7.2... -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/517#comment:13> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #517: make cabal install command support haddock options
by Hackage 28 Nov '11

28 Nov '11

#517: make cabal install command support haddock options ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Changes (by massysett): * cc: omari@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/517#comment:12> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #517: make cabal install command support haddock options
by Hackage 28 Nov '11

28 Nov '11

#517: make cabal install command support haddock options ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by massysett): Is there something I can do to help out with this ticket? Was there something wrong with the previous patch? cabal-install is a wonderful idea but due to the lack of this feature I simply don't use it. I wrote a shell script to automatically run the "runhaskell Setup" commands needed to install packages. Haddock docs are an order of magnitude more useful when the source is hyperlinked. I'm glad to help with this or even put a cash bounty on it. Or, I get the feeling that this comment is going to vanish into the ether where no interested developers will read it, so if any of the cc: people have an idea who to contact, please let me know, thanks :) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/517#comment:11> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #900: Regression in latest Cabal-1.13.3 snapshot
by Hackage 21 Nov '11

21 Nov '11

#900: Regression in latest Cabal-1.13.3 snapshot ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: major | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- The following cabal file below triggers an assertion fail on the second install: {{{ $ cabal --version cabal-install version 0.13.3 using version 1.13.3 of the Cabal library $ cabal install Resolving dependencies... Configuring foobar-0.2.0... Building foobar-0.2.0... Preprocessing library foobar-0.2.0... [1 of 1] Compiling FooBar ( FooBar.hs, dist/build/FooBar.o ) [1 of 1] Compiling FooBar ( FooBar.hs, dist/build/FooBar.p_o ) Registering foobar-0.2.0... Installing library in /home/hvr/.cabal/lib/foobar-0.2.0/ghc-7.2.2 Registering foobar-0.2.0... $ cabal install Resolving dependencies... Configuring foobar-0.2.0... cabal: Distribution/Simple/PackageIndex.hs:123:8-13: Assertion failed }}} Only when I unregister the installed package via `ghc-pkg unregister foobar` I can configure the package again... The cabal file causing this behaviour: {{{ name: foobar version: 0.2.0-git20111120 synopsis: none license: BSD3 license-file: LICENSE author: foo maintainer: foo@bar build-type: Simple cabal-version: >=1.10 library default-language: Haskell2010 exposed-modules: FooBar build-depends: base }}} The `FooBar` module is just a dummy empty module. This used to work previously, e.g. with {{{ $ cabal-0.11.2 --version cabal-install version 0.11.2 using version 1.12.0 of the Cabal library }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/900> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2