- cabal-devel - Haskell.org

Virtual packages
by Edward Z. Yang 02 Dec '11

02 Dec '11

Hello folks, I was thinking a little about how build flags that modify functionality are harmful for dependency resolution (pandoc and xmobar, I'm glaring at you), but authors will still use this feature because it's a lot easier than maintaining a bunch of separate packages for each different flag. It suddenly struck me, then, that what we actually needed was a mechanism not unlike what you see in traditional package managers, where a single Cabal file can specify multiple packages. pandoc.cabal might define 'pandoc' and 'pandoc-highlighting', and pandoc-highlighting can have different build dependencies, modules, etc. Module writers still need to arrange their APIs so that the extra functionality should be separable, but I don't see this as being too much of a problem. Mix-and-matching flags can be achieved by simply picking the extra virtual models as dependencies as necessary. What do you think? Cheers, Edward

3 6

Re: [Hackage] #576: Show reverse dependencies
by Hackage 02 Dec '11

02 Dec '11

#576: Show reverse dependencies --------------------------------+------------------------------------------- Reporter: Lenny222 | Owner: Type: enhancement | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: 1.6.0.1 Severity: normal | Keywords: dependencies Difficulty: easy (<4 hours) | Ghcversion: Platform: | --------------------------------+------------------------------------------- Changes (by PHO): * cc: pho@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/576#comment:9> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #299: Add changelog feature to hackagedb
by Hackage 02 Dec '11

02 Dec '11

#299: Add changelog feature to hackagedb --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | --------------------------------+------------------------------------------- Changes (by PHO): * cc: pho@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/299#comment:15> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #183: Provide "library-rank" in hackage
by Hackage 02 Dec '11

02 Dec '11

#183: Provide "library-rank" in hackage --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | --------------------------------+------------------------------------------- Changes (by PHO): * cc: pho@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/183#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[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