January 2009 - cabal-devel

[Hackage] #381: broken link cabal user guide
by Hackage 11 Mar '09

11 Mar '09

#381: broken link cabal user guide ----------------------------------+----------------------------------------- Reporter: luntain | Owner: Type: defect | Status: new Priority: low | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: minor | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.3 Platform: | ----------------------------------+----------------------------------------- http://www.haskell.org/cabal/release/latest/doc/users-guide/builders.html #setup-test contains a broken link with label: Distribution.Simple the fragment which contais the link reads: "See Distribution.Simple for information about creating hooks and using defaultMainWithHooks." -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/381> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #380: Ability to blacklist packages that are on hackage
by Hackage 11 Mar '09

11 Mar '09

#380: Ability to blacklist packages that are on hackage ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: wishlist blacklist Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Sometimes there are packages on hackage that I don't want to install, perhaps ever. Maybe there is a buggy release I'm trying to avoid, or something of that nature. So, my proposal is a user defined blacklist. I think the version specification could work just like that of a .cabal file. I also think cabal should tell you when it skips a dependency due to blacklisting. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/380> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #471: check for ambigious module names
by Hackage 11 Mar '09

11 Mar '09

#471: check for ambigious module names ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Consider an example: {{{ build-depends: base, extensible-exceptions }}} The package `base-4.0.0.0` and `extensible-exceptions-0.1.1.0` both provide the module `Control.Exception`. This means it is impossible to pick both packages as direct dependencies of any single package. We should check for this situation at configure time and/or in cabal- install when planning an installation plan. Actually trying to avoid this situation may be rather tricky and it is not expected to occur often. So a simple check may be sufficient. If it starts to occur often in practice then we could consider trying to get the constraint solver to avoid the situation (perhaps by adding it to the checks for if a package is installable at all, see #420). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/471> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #309: cabal install should recognize if package was already configured
by Hackage 09 Mar '09

09 Mar '09

#309: cabal install should recognize if package was already configured ---------------------------------+------------------------------------------ Reporter: bfr | 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: | ---------------------------------+------------------------------------------ If I first configure an unpacked package inside its source directory cabal configure --prefix=/my/path --flags=whatever and then afterwards do cabal install then the configure options I gave before are not recognized by the 'cabal install'. Instead, 'cabal install' without a package name argument should inspect whether the package is already configured and use whatever options have been set. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/309> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #294: Setup build should call Setup configure, if necessary
by Hackage 09 Mar '09

09 Mar '09

#294: Setup build should call Setup configure, if necessary ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: minor | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- If you change the Cabal description file of your project, you need to reconfigure it by calling ''Setup.lhs config'' (assuming that your Setup program is called ''Setup.lhs''). Since most editors don't know anything about Cabal, that requires you to have a shell open and type the command in question manually, which can get quite annoying, if you reconfigure often. ''Setup.lhs build'' recognizes the case, when the configuration has changed and dies with an error. It would be very useful, if it would call the ''configure'' command automatically instead, for example with the last used flags, or with a default set of flags configured in the description file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/294> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #477: re-configure when the .cabal file changes
by Hackage 09 Mar '09

09 Mar '09

#477: re-configure when the .cabal file changes ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- From http://trevion.blogspot.com/2008/11/cabal-is-fine-piece-of- software.html: {{{ One nice thing about Cabal is that it really helps you appreciate the different parts of the build process. For instance, suppose that I change my cabal metadata file, and then attempt to build my project, for instance by saying runghc Setup.hs build Cabal will helpfully reply: Setup.hs: interpreter.cabal has been changed, please re-configure. Notice how Cabal has helpfully here noticed that there’s work to be done, and not done it. I found that this really helped me appreciate the details of the build, rather than unhelpfully hiding those details behind some veneer of “automation”. }}} We can and should do this. It is annoying. The solution is to save the configure flags that the user gave originally and to use them again to re-configure. This could be a Read/Show style file like we have for the `LocalBuildInfo` or it could be a readable file like the cabal config file. A format and parser derived from the set of command line arguments. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/477> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #335: GHC_PACKAGE_PATH disrespected
by Hackage 09 Mar '09

09 Mar '09

#335: GHC_PACKAGE_PATH disrespected ----------------------------+----------------------------------------------- Reporter: cjs | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: Other Unix | ----------------------------+----------------------------------------------- Looks like cabal doesn't even use GHC_PACKAGE_PATH at all. {{{ $ unset GHC_PACKAGE_PATH $ ghc-pkg list binary /usr/pkg/lib/ghc-6.8.3/package.conf: $ export GHC_PACKAGE_PATH=/my/package.conf:/usr/pkg/lib/ghc-6.8.3/package.conf $ ghc-pkg list binary /usr/pkg/lib/ghc-6.8.3/package.conf: /my/package.conf: binary-0.4.1 $ runghc Setup.hs configure Configuring mypackage-1.0... Setup.hs: At least the following dependencies are missing: binary -any }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/335> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #337: --disable-split-objs has wrong help string
by Hackage 09 Mar '09

09 Mar '09

#337: --disable-split-objs has wrong help string ----------------------------+----------------------------------------------- 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.3 Platform: Mac OS | ----------------------------+----------------------------------------------- I did: $ ./Setup.lhs configure --help ... --enable-split-objs split library into smaller objects to reduce binary sizes (GHC 6.6+) --disable-split-objs split library into smaller objects to reduce binary sizes (GHC 6.6+) ... It should read: --disable-split-objs retain library as one object file (GHC 6.6+) $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.3 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/337> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #346: Add a warning for synopsis being a prefix of the description
by Hackage 09 Mar '09

09 Mar '09

#346: Add a warning for synopsis being a prefix of the description ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Many packages provide useless descriptions, just repeating the synopsis. Three (all from different authors, and only looking at those with "string" as a substring of the name!) include stringtable-atom, bytestring-csv and packedstring. Suggestion: Give a warning when the synposis is a prefix of the description. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/346> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #371: cabal-install can break installed packages by rebuilding dependents
by Hackage 09 Mar '09

09 Mar '09

#371: cabal-install can break installed packages by rebuilding dependents ---------------------------------+------------------------------------------ Reporter: duncan | 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: | ---------------------------------+------------------------------------------ Install plans sometime involve rebuilding a package. This is not a safe operation however. Rebuilding a package can and does change its ABI. The ideal solution is to use a persistent package store like nix. That would mean we do not replace any installed package, just add new instances. In the mean time however one solution would be to extend an install plan the re-installs a package such that it rebuilds all reverse dependencies too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/371> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1