June 2008 - cabal-devel

patch applied (cabal-branches/cabal-1.2): TAG GHC 6.8.3 release
by Ian Lynagh 18 Jun '08

18 Jun '08

Wed Jun 18 06:28:06 PDT 2008 Ian Lynagh <igloo(a)earth.li> tagged GHC 6.8.3 release View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008061813…

1 0

patch applied (cabal-branches/cabal-1.2): TAG 1.2.4.0
by Ian Lynagh 18 Jun '08

18 Jun '08

Wed Jun 18 06:22:22 PDT 2008 Ian Lynagh <igloo(a)earth.li> tagged 1.2.4.0 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008061813…

1 0

patch applied (cabal-branches/cabal-1.2): TAG 2008-06-06
by Ian Lynagh 18 Jun '08

18 Jun '08

Thu Jun 5 16:55:32 PDT 2008 Ian Lynagh <igloo(a)earth.li> tagged 2008-06-06 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008060523…

1 0

ANNOUNCE: cabal-install 0.5
by Duncan Coutts 18 Jun '08

18 Jun '08

cabal-install 0.5 ================= cabal-install version 0.5 is out: http://haskell.org/cabal/download.html or get it from hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cabal-install If you are already using a cabal-install pre-release then you can just: $ cabal update $ cabal install cabal-install New features in cabal-install ============================= Command line improvements ------------------------- The most immediately noticeable thing is that the command line interface now has all the commands that runhaskell Setup.hs has. Of course it still has the features to download and install packages from hackage. It also gained an upload command. So it now provides a command line interface to the whole Cabal/Hackage system. There’s no need to use runhaskell Setup.hs ever again. There is also bash command line completion support included which I find is a great time saver. Installing and upgrading ------------------------ The next big thing is that it includes a new package dependency resolution system that finds correct and sensible solutions more of the time and has better default behaviour. The new behaviour should be similar to other package managers that people are used to. For example, suppose you’ve got xmonad-0.5 installed and version 0.7 is the latest on hackage, then $ cabal install xmonad will install xmonad-0.7. The older version, xmonad-0.5, will remain installed. The behaviour of install is to upgrade as little as possible to satisfy your request, but sometimes you want to upgrade all the dependencies too. Supposing now that we have xmonad-0.7 installed, but we’re still using X11-1.4.1 and the latest version on hackage is X11-1.4.2, then $ cabal upgrade xmonad will install X11-1.4.2 and *re-install* xmonad-0.7, this time built against the newer X11-1.4.2. So in general, the install command will install the latest version of things but will try and use any existing installed versions of dependencies while the upgrade command will also try to use the latest versions of all dependencies. As a special case, cabal upgrade on its own will try to upgrade all the packages that you have installed. For both command there is a --dry-run flag so you can see what would be installed without actually doing it. Hugs ---- Yes, it even works with hugs. That is, cabal-install built by ghc can manage the installation of packages for hugs. In principle cabal-install should be able to be run by hugs but currently the zlib binding is using a function that hugs does not support. Note that for hugs, Cabal does not know what packages are already installed because there is no equivalent of the package database that ghc has. So that means cabal-install cannot do very sensible installation planning. It should work ok so long as all the dependencies are already installed. Windows ------- Yes, it even works on Windows. The one caveat is that cabal-install cannot currently upgrade itself because Windows makes it hard for a process to overwrite its own executable file. It needs more complex trickery with the Win32 API. In the meantime the workaround is to rename the cabal.exe file first eg to cabal-foo.exe, then run cabal-foo install cabal-install. Build reporting --------------- One feature that made it into this release is build reporting. cabal-install keeps logs of all packages that you install (at least packages from hackage, not local ones). It records a bit of information about each package, in particular whether the outcome was successful or not. You can see these build reports in ~/.cabal/packages/$server/build-reports.log. For example, there is one from my machine for xmonad: package: xmonad-0.7 os: linux arch: x86_64 compiler: ghc-6.8.2 client: cabal-install-0.5.1 flags: -testing small_base dependencies: X11-1.4.2 base-3.0.1.0 containers-0.1.0.1 directory-1.0.0.0 mtl-1.1.0.0 process-1.0.0.0 unix-2.3.0.0 install-outcome: InstallOk docs-outcome: NotTried tests-outcome: NotTried The plan in the longer term is to let people upload these build reports to hackage so we can get a wider range of testing data about the packages on hackage. Duncan

1 0

ANNOUNCE: Cabal 1.4
by Duncan Coutts 18 Jun '08

18 Jun '08

Cabal 1.4 ========= Cabal version 1.4 is out: http://haskell.org/cabal/download.html The user guide and API documentation are also available from the download page. You can also get it from hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal Release notes ============= There are no huge new features in the Cabal library itself, though there are a number of incremental improvements and lots of bug fixes. The main new feature is that is supports a significantly improved version of cabal-install. You can see a summary of the changes in the change log: http://haskell.org/cabal/release/latest/changelog A few items in particular are changes in existing behaviour: * All .cabal files are treated as UTF-8 and must be valid * Stricter parsing for version strings, eg disallows "1.05" * Default prefix for --user installs is now $HOME/.cabal Compatibility ------------- We have tried to preserve compatibility with all packages that worked with the Cabal-1.2.x series. That is, packages that can be built using Cabal (including custom Setup.hs scripts) but not packages that directly import and use the Cabal API. Packages that directly import and use the Cabal api will need updating. This affects packages that build distro packages for example, rpm debs etc. Bugs and feature requests ------------------------- This is an excellent opportunity to make sure your favourite bug or feature request is properly described in our bug tracker: http://hackage.haskell.org/trac/hackage/ To help us guide development priorities please add yourself to the ticket's cc list and describe why that bug or feature is important to you. Credits ======= On behalf of the Cabal hackers and the community generally I'd like to thank the large number of people who have contributed patches during this development series. Previously I was rather worried that we were not getting enough contributors to fix bugs and do new feature development, but now I'm very pleased. Get involved ============ Of course there's still a lot to do! We have big plans for Cabal-2.0, cabal-install and the Hackage website. So if you're interested in helping out with this core infrastructure project then: * subscribe to the cabal-devel mailing list: http://www.haskell.org/mailman/listinfo/cabal-devel * grab the source: http://haskell.org/cabal/code.html * read the guide to the source code: http://hackage.haskell.org/trac/hackage/wiki/SourceGuide * take a look at our list of bugs and feature requests: http://hackage.haskell.org/trac/hackage/report/12 especially the easy tickets: http://hackage.haskell.org/trac/hackage/report/13 Duncan

1 0

Cabal uses incorrect proxy settings
by Neil Mitchell 17 Jun '08

17 Jun '08

Hi, I just tried: C:\Neil\hoogle>cabal update Downloading package list from server 'http://hackage.haskell.org/packages/archive' Warning: invalid http proxy uri: "wwwcache.sns.york.ac.uk:8080" Warning: proxy uri must be http with a hostname Warning: ignoring http proxy, trying a direct connection Obviously it tried to go via the York cache, which is wrong. So I checked the IE proxy settings, and found the attached screenshot. i.e. the settings are as mentioned, but the checkbox to use those settings is disabled. If you tell me which bit of the registry this gets read from, I'll happily copy those keys. Thanks Neil

2 4

patch applied (cabal-install): Default to global installs on Windows
by Duncan Coutts 16 Jun '08

16 Jun '08

Mon Jun 16 15:38:47 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Default to global installs on Windows User installs by default elsewhere. Note that this default only affects new config files. Existing windows users will need to change their config file or delete it and let it be re-created. M ./Hackage/Config.hs -9 +18 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080616223847-adfee-…

1 0

Cabal install performs worse on Hugs
by Neil Mitchell 16 Jun '08

16 Jun '08

Hi, Using Cabal 1.4 Branch and Cabal-install HEAD: C:\Neil\uniplate>cabal install --hugs Resolving dependencies... cabal: internal error: could not construct a valid install plan. The proposed (invalid) plan contained the following problems: Package uniplate-1.1 has an invalid configuration, in particular: the package has a dependency base >=3 but no package has been selected to sati sfy it. the package has a dependency containers -any but no package has been selected to satisfy it. the package has a dependency mtl -any but no package has been selected to sati sfy it. But doing it the old way: C:\Neil\uniplate>runhaskell Setup configure --hugs Configuring uniplate-1.1... C:\Neil\uniplate>runhaskell Setup build Preprocessing library uniplate-1.1... Building uniplate-1.1... C:\Neil\uniplate>runhaskell Setup install Installing: C:\Program Files\Haskell\hugs\packages\uniplate Registering uniplate-1.1... It seems like if cabal install is incapable of doing anything good on Hugs, it should at least try to see if it works already. Thanks Neil

2 3

Misplacement of installed binaries
by Neil Mitchell 16 Jun '08

16 Jun '08

Hi, Using Cabal-1.4 and cabal-install head, installing cabal-install puts the binary at: "C:\Documents and Settings\Administrator\Application Data\cabal\bin" That seems like a bad choice of location for installed program files on Windows. Application Data is not for putting binaries into. It is installing programs, and they should go in C:\Program Files\Haskell\bin, as they did with Cabal-1.2. Is there a reason for changing the install location on Windows? Thanks Neil

2 6

Depsolver won't install some installable packages
by Darrin Thompson 16 Jun '08

16 Jun '08

Is this buggy behavior? Installing yi... ... setup: alex version >=2.0.1 && <3 is required but it could not be found. cabal: Error: some packages failed to install: yi-0.3 failed during the configure step. The exception was: exit: ExitFailure 1 $ cabal install alex Resolving dependencies... Downloading alex-2.2... [1 of 1] Compiling Main ( Setup.lhs, dist/setup/Main.o ) ... I observed similar behavior with happs depending on happy. I had to issue an install command for happy and then happs-hsp-template installed. I would guess that what alex and happy have in common is that they are indirect (second order?) dependencies of the user's specified package. Pure speculation on my part. -- Darrin

2 1