March 2009 - cabal-devel

[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] #199: when installing a new version of GHC, there should be a way to upgrade my packages
by Hackage 18 Jul '09

18 Jul '09

#199: when installing a new version of GHC, there should be a way to upgrade my packages ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ If I have version 6.6 of GHC installed, with packages foo, bar, and bang, and I install ghc 6.8, I'd like a way to automatically install foo, bar, and bang. This could be part of GHC's installation script possibly, or maybe a feature of cabal install. cabal can check the installed packages for the previous version of GHC and "cabal install" them. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/199> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 10

[Hackage] #330: Take non-haddock documentation in account
by Hackage 01 Jul '09

01 Jul '09

#330: Take non-haddock documentation in account ----------------------------+----------------------------------------------- Reporter: fons | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- The generation and installation of Non-Haddock documentation (README and INSTALL files, LaTeX and Docbook tutorials/guides, Haskell examples using the package in question) is not currently taken in account by Cabal. Making Cabal understand how to generate documentation for all those formats would probably be too ambitious, but it could be eased (e.g. letting the user provide Makefiles instead of creating custom hooks). More importantly, the installation of documentation would be much easier with a new package property such as "doc-files" ("data-files" nor "extra- source-files" are semantically suitable). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/330> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #325: SHGetFolderPath requiered to configure cabal 1.4
by Hackage 30 Jun '09

30 Jun '09

#325: SHGetFolderPath requiered to configure cabal 1.4 ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- i try to install cabal with ghc 6.8.3 on XP. i get the error message GHCi could not find the following symbols SHGetFolderPath i saw some old bugs mentioning this problem - what is a current fix? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/325> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #458: inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure
by Hackage 26 Jun '09

26 Jun '09

#458: inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- We have a mismatch between the cabal Setup scripts which ignore `LDFLAGS` etc and provide `--extra-lib-dirs` instead, and some `./configure` scripts which grab the `CCFLAGS` etc and bung them into a `.buildinfo` file. This is bad because it means --extra-lib-dirs does not work for those packages and it also means that those packages consult the CCFLAGS etc and others do not. It's quite an inconsistent user interface. We should try to make it more consistent. One approach would be for cabal to consider the CCFLAGS etc, to combine them with the flags passed on the command line and those specified in the .cabal file. (We have code to analyse CC/LD/CPP flags and to split them up into the standard BuildInfo fields.) Then for configure scripts we could pass the whole lot. The danger of course is that the configure scripts duplicate it all and put it into a .buildinfo file. Another tempting option is to call configure with a clean environment so that it cannot pick up these vars. Unfortunately that might break some existing packages. We should be careful with the use of these env vars though, because while it's fine to change the user interface to cabal-install, the interface to the Setup.hs is a machine interface and the more we require of it, the more has to be implemented by every different build system. A case in point is the curl package. It has a .buildinfo file like: {{{ cc-options: @CPPFLAGS@ ld-options: @LDFLAGS@ }}} The `./configure` script checks: {{{ AC_TRY_CPP([#include <curl/curl.h>],,[no_curl=yes]) }}} Which uses the `CPPFLAGS`. So it's adding an extra package-specific user interface by consulting these environment variables. At the same time the configure script ignores the `--extra-lib-dirs=` and `--extra-include-dirs=` Setup.hs command line flags. This means that users doing what is advertised will find the package does not work. Indeed changing to `build-type: Simple` and deleting the configure script makes it work perfectly. So this mismatch is clearly harmful. See also #262 which should make these checks redundant. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/458> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #435: ban upwardly open version ranges in dependencies on base
by Hackage 15 Jun '09

15 Jun '09

#435: ban upwardly open version ranges in dependencies on base ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- This is wrong! {{{ build-depends: base }}} This is still wrong! {{{ build-depends: base >= 3 }}} Each major release of the base package breaks most packages. Packages should specify an upper bound on the base version. Eg: {{{ build-depends: base >= 3 && < 4 }}} or equivalently: {{{ build-depends: base == 3.* }}} Cabal should check for this and suggest a sensible upper version on the base package, given that we know that base follows the package version policy. Note this is a special case for base but in general we should do this for all packages that opt-in to the versioning policy (see #343). Doing it for all such packages is a medium term goal. Doing it for base is quick and easy and has a lot of immediate benefits for the next release of base. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/435> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

[Hackage] #497: on package not found error: mention "cabal update"
by Hackage 14 Jun '09

14 Jun '09

#497: on package not found error: mention "cabal update" ---------------------------------+------------------------------------------ Reporter: Martijn | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Together with the "There is no package named .." error, a message could be provided that updating the package list might solve the problem. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/497> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #417: Package description: Links from Categories to Package list fragments
by Hackage 11 Jun '09

11 Jun '09

#417: Package description: Links from Categories to Package list fragments ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.3 Platform: | ----------------------------------+----------------------------------------- E.g. cabal-install is in Category Distribution. Thus in the package description at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cabal-install the word "Distribution" should be a link to http://hackage.haskell.org/packages/archive/pkg- list.html#cat:Distribution This way one can easily browse for other packages of the same category. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/417> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #273: Provide a stable address for current Haddock documentation
by Hackage 11 Jun '09

11 Jun '09

#273: Provide a stable address for current Haddock documentation ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Documentation for version 0.1.1 of the Derive package is at http://hackage.haskell.org/packages/archive/derive/0.1.1/doc/html/ - but as soon as I upload a new version any documentation links will become out of date. It would be very useful if there was a stable URL where the documentation of the latest version of a package could be found. -- Neil Mitchell -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/273> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #488: Include links to GHC documentation in packages' haddock docs
by Hackage 11 Jun '09

11 Jun '09

#488: Include links to GHC documentation in packages' haddock docs --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- It would be really nice if packages' haddock documentation didn't have broken (well, missing) links whenever it refers to GHC core packages that aren't also on hackage. Even nicer would be if dependencies on GHC core packages also linked to their Haddock documentation. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/488> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 8