August 2008 - cabal-devel

patch applied (cabal-install): allow tilde in hackage server URIs
by Duncan Coutts 15 Aug '08

15 Aug '08

Fri Aug 15 07:27:35 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * allow tilde in hackage server URIs report and fix from Nicolas Frisby <nicolas.frisby(a)gmail.com> (code had changed slightly so the original patch didn't apply cleanly) M ./Distribution/Client/Config.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080815142735-adfee-…

1 0

[Hackage] #229: Build C sources using the system's C compiler directly
by Hackage 15 Aug '08

15 Aug '08

#229: Build C sources using the system's C compiler directly ----------------------------+----------------------------------------------- Reporter: guest | 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: | ----------------------------+----------------------------------------------- Currently Cabal builds C sources by going via ghc. On some platforms this introduces some limitations (Windows especially, I think). See this conversation for an example where it would be useful: http://www .mail-archive.com/haskell-cafe(a)haskell.org/msg37179.html -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/229> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #225: allow installing just specific bits, like just docs
by Hackage 15 Aug '08

15 Aug '08

#225: allow installing just specific bits, like just docs ----------------------------+----------------------------------------------- Reporter: duncan | 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: | ----------------------------+----------------------------------------------- Sometimes people would like to build and install just part of a cabal project, e.g. the documentation or one of the libraries or binaries. Specific use-cases are packaging for OS distro's and generating Haddock docs for code that was installed without it (cf the current state of Debian-stable). Igloo proposes the following user interface: ----- As long as docs, license and binaries can be (de)selected individually I don't really mind. If you want a concrete suggestion, we could have `--foo` and `--no-foo` for each thing, with the default being `--all` and the command line being processed left-to-right, e.g. {{{ cabal install --no-haddock-interfaces --docs --no-html }}} would install * all (which wouldn't actually contain anything) * docs (which wouldn't actually contain anything) * haddock-interfaces * license * everything under binaries ----- I broadly agree, but am slightly concerned there are dependencies amongst the various things that his syntax does not respect (e.g. one may need to install the libraries - e.g. one depending on a foreign library - in order to get a binary working). So either we have to vet the command lines or coarsen the flags. I hope Duncan and Igloo can draw on their packaging experience and determine what is actually useful. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/225> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

Re: [Hackage] #91: Building executables that use Template Haskell for profiling
by Hackage 15 Aug '08

15 Aug '08

#91: Building executables that use Template Haskell for profiling ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.1.4 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.5 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * milestone: Cabal-1.6 => Cabal-1.8 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/91#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #24: Cabal shouldn't try to build GHCI libs on platforms without GHCI
by Hackage 15 Aug '08

15 Aug '08

#24: Cabal shouldn't try to build GHCI libs on platforms without GHCI ------------------------------------+--------------------------------------- Reporter: jgoerzen(a)complete.org | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.2.1 | Platform: Linux ------------------------------------+--------------------------------------- Changes (by duncan): * milestone: Cabal-1.6 => Cabal-1.8 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/24#comment:8> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #93: Incorrect permissions on library install
by Hackage 15 Aug '08

15 Aug '08

#93: Incorrect permissions on library install ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.1.4 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * milestone: Cabal-1.6 => Cabal-1.8 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/93#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #212: Overhaul Cabal's testsuite
by Hackage 15 Aug '08

15 Aug '08

#212: Overhaul Cabal's testsuite ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: very hard (<1 week) | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- The current testsuite based on HUnit is almost completely bitrotted. Anyone who wants to take this on has essentially a completely clean slate to work from. The current system is split into two parts. There are hunit tests in many of the modules guarded by #ifdef DEBUG. Then there are external tests in the `tests/` subdirectory. The #ifdef DEBUG style is annoying since it involves using more CPP than seem really necessary. A couple notes from the old `TODO` file: {{{ ** add a make target or command for tests we know will fail? ** setup test suite to run on --push? ** redirect non-hunit outputs to a file? }}} One possibility that is available to us now that was not before is using the hackage collection as part of a regression test. For example it should always be possible to parse all the `.cabal` files in the index. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/212> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

Re: [Hackage] #42: implement hugs-pkg?
by Hackage 15 Aug '08

15 Aug '08

#42: implement hugs-pkg? ----------------------------+----------------------------------------------- Reporter: ijones | Owner: ross(a)soi.city.ac.uk Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * owner: => ross(a)soi.city.ac.uk Comment: So I'm happy with the idea that for hugs and nhc that we do not need a distinct concept of a package database. The package database can coincide with the location where packages are installed, and hugs/nhc just look in that dir for their packages. Cabal would also look there for the `InstalledPackageInfo` files. So the package db and the libdir are really the same thing. Hugs already looks in `~/lib/hugs/*` for package directories. So for hugs there are two things to do: * make Cabal and hugs agree on where the per-user install path for package should be. Currently cabal-install puts them in `~/.cabal/lib/hugs/*` (or something like that). * get the next release of hugs to include the `InstalledPackageInfo` files for all the packages that it comes with. This will enable cabal to know what packages are installed by reading these files, just as it does with ghc by asking ghc-pkg for the equivalent info. I'm not sure which of Hugs or Cabal should change on the issue of where packages are instelled per-user. I know people would scream if cabal installed things in `~/lib` by default, but perhaps if they're using hugs then they don't care. If we have to get hugs to change anyway to include the `InstalledPackageInfo` files then adding an extra default search path entry for a location under `~/.cabal/` would not be any more work. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/42#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #301: No way to reinstall current version of a package
by Hackage 14 Aug '08

14 Aug '08

#301: No way to reinstall current version of a package ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.3 Platform: | ----------------------------------+----------------------------------------- cabal-install currently offers no way of reinstalling a version of a package which is already installed. If one has been messing around with libraries behind Cabal's back, this might be useful, if for no other reason than to assuage one's worries regarding link errors. Ideally a flag `--force` or whatever could be given to `cabal upgrade` and `cabal install`, which would make bypass the check for whether the package exists. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/301> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #297: cabal fetch command don't fetch packages those have already been installed
by Hackage 14 Aug '08

14 Aug '08

#297: cabal fetch command don't fetch packages those have already been installed ---------------------------------+------------------------------------------ Reporter: chylli | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ when I saw cabal help: fetch Downloads packages for later installation or study. I think I can fetch any packages to study. But in fact it not. They only download packages those have not installed yet. I think this help info can mislead users. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/297> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5