- cabal-devel - Haskell.org

[Hackage] #486: cabal-install's bootstrap.sh has no recovery strategy in case of errors
by Hackage 02 Feb '09

02 Feb '09

#486: cabal-install's bootstrap.sh has no recovery strategy in case of errors ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When attempting to install cabal-install for the first time, on a unix system, using the supplied bootstrap.sh script, if anything goes wrong during the script, it carries on regardless, leaving the install process in an inconsistent and potentially unrecoverable state. I tried to install cabal-install for ghc-6.8.2, which was originally supplied with an older version of Cabal (1.2.3.0), on a Mac. For some reason (probably another Cabal bug), my existing $HOME/.cabal /powerpc-darwin-6.8.2 directory had the wrong permissions. So when bootstrap.sh built Cabal-1.6.0.1 and tried to install it, it could not. I fixed the permissions and ran bootstrap.sh again: It built and registered Cabal-1.6.0.1 correctly this time, but did nothing else, except print the error "Sorry, something went wrong". Running the subsequent script commands manually (to configure, build and install HTTP, zlib, and cabal- install) also did nothing. For instance: {{{ $ runghc Setup configure --user && runghc Setup build && runghc Setup install $ }}} Note the lack of any output whatsoever. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/486> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #487: print less useless info during builds
by Hackage 02 Feb '09

02 Feb '09

#487: print less useless info during builds ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: minor | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Here's an example from a blog post: {{{ $ cabal update $ cabal install gofer-prelude Resolving dependencies... Downloading gofer-prelude-2.30... Configuring gofer-prelude-2.30... Preprocessing library gofer-prelude-2.30... Building gofer-prelude-2.30... [1 of 1] Compiling Prelude.Gofer ( Prelude/Gofer.hs, dist/build/Prelude/Gofer.o ) /usr/bin/ar: creating dist/build/libHSgofer-prelude-2.30.a Installing library in /home/dons/.cabal/lib/gofer-prelude-2.30/ghc-6.10.1 Registering gofer-prelude-2.30... Reading package info from "dist/installed-pkg-config" ... done. Writing new package config file... done. }}} Which bits are useful and useless? I mean at the standard verbosity level. I bet this is useless: {{{ Preprocessing library gofer-prelude-2.30... }}} Does it actually do any pre-processing? See also #475. Useless: {{{ /usr/bin/ar: creating dist/build/libHSgofer-prelude-2.30.a }}} This is produced by the `ar` program. We can however pass it a flag to tell it to be quiet. Not especially useful: {{{ Installing library in /home/dons/.cabal/lib/gofer-prelude-2.30/ghc-6.10.1 }}} This message is generated by Cabal. At the default verbosity level we probably only need something like "Installing gofer-prelude-2.30..." Useless: {{{ Reading package info from "dist/installed-pkg-config" ... done. Writing new package config file... done. }}} This message is generated by ghc-pkg. We should patch ghc-pkg to not be so verbose by default. That message is only needed at a higher verbosity level. So if we get all these things fixed it'd look like: {{{ $ cabal update Downloading package list from hackage.haskell.org $ cabal install gofer-prelude Resolving dependencies... Downloading gofer-prelude-2.30... Configuring gofer-prelude-2.30... Building gofer-prelude-2.30... [1 of 1] Compiling Prelude.Gofer ( Prelude/Gofer.hs, dist/build/Prelude/Gofer.o ) Installing gofer-prelude-2.30... Registering gofer-prelude-2.30... }}} This is assuming the package in question doesn't actually need any pre- processing. Even the pre-processing message could be elided if we don't think it'll take that long. I wonder if we can get ghc to not tell us the source and object file locations. While it is sometimes useful while hacking, for batch builds we do not need it. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/487> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #483: separate preferred versions into hacks and real preferred versions
by Hackage 01 Feb '09

01 Feb '09

#483: separate preferred versions into hacks and real preferred versions --------------------------------+------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- We have the "preferred-versions" file in the hackage index. This is used by cabal-install. It has a dual purpose which we should try to separate. The first is for things like "base < 4", to make up for the fact that so many older packages do not specify a version of base. This is basically a hack. It's not that we really would prefer people to use base 3. On the other hand it is useful to be able to put experimental versions of packages on hackage and not have them be the default version. For example HaXml still declares that 1.13.x is the stable version with 1.19.x the current development version. In the latter case the default (unversioned) package package should point to the preferred version (ie 1.13.x). So it would be useful to separate the hacks from the real preferred versions. The cabal-install tool might treat the two slightly differently and the hackage db website should only consider the latter. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/483> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #482: survey ./configure scripts in hackage packages
by Hackage 01 Feb '09

01 Feb '09

#482: survey ./configure scripts in hackage packages ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: Windows | ----------------------------+----------------------------------------------- Many packages use `./configure` scripts which make them hard to use on Windows as it requires MSYS. Ideally packages could do these custom checks in `Setup.hs` scripts or very common checks might be possible in the Simple build system itself. This task is to do a survey of the packages on hackage that use `./configure` scripts and identify the most common checks that they are doing. Specifically we would like to know what number of `./configure` scripts could be eliminated by implementing various features in Cabal (either to do the checks directly or to make it easier to do the checks in per-package `Setup.hs` scripts). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/482> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #472: new field for version policy
by Hackage 01 Feb '09

01 Feb '09

#472: new field for version policy ----------------------------+----------------------------------------------- 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: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- We would like packages to be able to describe what version policy they use. One common policy that we have been discussing is called the [http://haskell.org/haskellwiki/Package_versioning_policy Package versioning policy] or PVP for short. In particular we would like packages to be able to opt-in to following this policy. It would enable hackage to enforce the policy (with a suitable API-checking tool) which should provide a strong guarantee for client packages. In addition it would allow hackage and cabal to make suggestions for packages about dependencies on packages that follow the polciy. For example it could suggest not using upwardly open version ranges. So we would like a reasonably extensible syntax for packages to specify what version policy they follow. One suggestion is: {{{ version-policy: PVP-1 }}} That is named (and versioned) policies. The names would have to be well known and defined elsewhere. Only known policies could only be enforced. As with other similar meta-data, the value should be parsed but allow unknown policies. Hackage could reject unknown policies, but it would enable people to make in-house modifications to add new policies. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/472> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #434: Let packages opt-in to the Package Versioning Policy
by Hackage 01 Feb '09

01 Feb '09

#434: Let packages opt-in to the Package Versioning Policy ----------------------------+----------------------------------------------- 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: | ----------------------------+----------------------------------------------- Package version numbers and version constraints on dependencies are proxies for API compatibility. It is hard for people to specify the dependencies correctly and we would like to improve their quality. We have the [http://haskell.org/haskellwiki/Package_versioning_policy Package versioning policy] which says how the package version number relates to API changes. What we want is a mechanism by which package authors can opt-in to the versioning policy. We should then get hackage to check that the package really is following the policy. Just as important we can use the fact that a package does follow the policy to give suggestions to package authors. For one thing we can discourage or ban upwardly open version ranges and provide a suggestion on what upper version bound to use. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/434> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #368: The "optimization" option in ~/.cabal/config does not work
by Hackage 01 Feb '09

01 Feb '09

#368: The "optimization" option in ~/.cabal/config does not work ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.4.0.1 Severity: minor | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ Running cabal install $package with "optimization: True" uncommented in ~/.cabal/config results in an error: cabal: Command.optionToFieldDescr: feature not implemented -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/368> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #446: Can't set path to tools in ~/.cabal/config
by Hackage 01 Feb '09

01 Feb '09

#446: Can't set path to tools in ~/.cabal/config ---------------------------------+------------------------------------------ Reporter: awick | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ The config file for cabal-install lets me set all sorts of useful paths, except for the non-compiler tools. In other words, there's no config file mapping for the --with-PROG or --PROG-options flags, which would be really convenient. (At least, when I tried the obvious versions, it didn't work. Maybe missing docs somewhere?) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/446> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

darcs patch: Fix message suggesting the --executables flag
by Samuel Bronson 01 Feb '09

01 Feb '09

Sat Jan 31 20:07:08 EST 2009 Samuel Bronson <naesten(a)gmail.com> * Fix message suggesting the --executables flag

1 0

patch applied (cabal): Improve the error message for missing foreign libs and make it fatal
by Duncan Coutts 31 Jan '09

31 Jan '09

Sat Jan 31 10:48:13 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Improve the error message for missing foreign libs and make it fatal The check should now be accurate enough that we can make it an error rather than just a warning. M ./Distribution/Simple/Configure.hs -8 +28 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090131184813-adfee-55b6a46f…

1 0