May 2008 - cabal-devel

[Hackage] #251: link to the latest version of a package tar file
by Hackage 20 Mar '10

20 Mar '10

#251: link to the latest version of a package tar file ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- Dan Corson suggests: it would be good to have links to latest versions of a package file available for download. for example: something like {{{ http://hackage.haskell.org/packages/archive/arrows/latest.tar.gz }}} would be a link to {{{ http://hackage.haskell.org/packages/archive/arrows/0.4/arrows-0.4.tar.gz }}} this would greatly simplify automating installs. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/251> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

2 5

[Hackage] #284: Cannot upload packages that require specific cabal versions
by Hackage 18 Mar '10

18 Mar '10

#284: Cannot upload packages that require specific cabal versions --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- I have a package that requires a custom Setup.lhs.The package works for ghc 6.8.x and 6.6.x and, thus, the Setup.lhs script was designed to work with Cabal 1.2.x, the one that comes with ghc 6.8.x. This is clearly indicated in the cabal-version field. However, if I try to upload this package to hackage I get this error: {{{ hint-0.2.0.1/hint.cabal: This package requires Cabal version: >=1.2&&<1.3 }}} As a workaround I used cabal-version: >= 1.2 but now, although the description explicitly says that it works with ghc 6.8.x, hackage indicates that it fails to build. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/284> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #215: Overhaul support for package's tests
by Hackage 15 Mar '10

15 Mar '10

#215: Overhaul support for package's tests ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- The current support for running package's testsuites is almost uniformly unused and packages instead implement ad-hoc solutions which makes it hard for users to run the testsuites and impossible to automate on hackage. The current support is so trivial anyone who takes this task on can ignore it and start with a clean slate. A [http://www.haskell.org/pipermail/cabal-devel/2008-January/001661.html thread on the issue]. Here are some ideas for possible requirements: * Support tests even in the `Simple` build system. Do not require using the `build-type: Custom` just to be able to use tests. * Define a standard interface for returning test results from a testsuite to Cabal so they can be included into a build report and could be published on the hackage website or some other custom in-house test server. * Support for above interface in `QuickCheck` and `HUnit`. * Support for HPC when running testsuite programs, and gathering coverage results, again for reporting purposes. * We want to be able to run tests on a library that is not installed yet. This will rely on support in Cabal for registering a package inplace in a local package db, and building test code against that. * What about performance tests? What format should that use for reporting? The emphasis is on automation. A lot of interesting information becomes available with enough automation. For example we could compare on hackage which packages have more comprehensive testsuites (measured by HPC coverage). Or we could track performance over time. Once the data is available there is a lot we could do with it. It's not just for a public hackage server, developers could use this privately too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/215> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

[Hackage] #234: track installed files to allow uninstall
by Hackage 24 Jan '10

24 Jan '10

#234: track installed files to allow uninstall -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- `cabal-install` needs to be able to track all the files it installs so that it'll be possible to uninstall packages. The copy/install code should be extended to be able to generate a list of files and hashes of files that will be installed. `cabal-install` could use that to write out a manifest file and use that later to allow uninstalling. One solution might be to restructure the install code to gather the source files that it would install rather than just doing it. Once that list of files is known we can copy them all in one go, and do other things like check for clashing target files and generate manifests etc. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/234> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

[Hackage] #207: Jumping to code every and anywhere: What about installing source files and a tag file along with haddock and lib files ?
by Hackage 14 Jan '10

14 Jan '10

#207: Jumping to code every and anywhere: What about installing source files and a tag file along with haddock and lib files ? --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: misc | Version: HEAD Severity: normal | Keywords: tags source tagfile Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------+------------------------------------------------- == Introduction == I personally depend on tags because the source code only tells what is really going on. So it would be incredible useful to not only get information using ghci after loading libs but also beeing able to jump to all functions you might be using anywhere (The only solution providing this in all cases is uning tags, right? Because cpp defines can introduce new functions.. To be able to jump to the code source must be installed along with libs (the way you can optionally install haddock docs) == Use case: == setup configure --with-tags --install-source (or something like that) setup build && setup install do this for each dependency given in the .cabal file (VIM:) let tags+=system('ghc-pkg --query-tagfile-location haskell98-1.0.0.0') == Issues: == * Which tool to generate tag files? * ghc(i) when targeting ghc * the hasktags program shipping with ghc * some others? * Tagfile path type relative or absolute? * absolute: After moving/ installing the sources the tagfile must be patched * relative: Do editors take the right base directory to find source files? * When to invoke the tagfile generating program? * Perfect case would be after all preprocessing has been done (Thus the tagging program should understand line number changing comments!) * Template Haskell? ( This is really tricky I think ) * Hmm sorted tagfiles would be useful as well :) == alternatives ? == If you do not think this is useful (mandatory?) how do you lookup code? (Yes I know hoogle :) perhaps using Eclipse or Visual Studio? I'd like to start implementing this somehow the next weeks. So don't hesitate and start discussing Marc Weber -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/207> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

2 5

[Hackage] #244: Add Changelog summary feature to sdist
by Hackage 22 Dec '09

22 Dec '09

#244: Add Changelog summary feature to sdist ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- In a discussion with Audrey Tang, she mentioned that a very nice feature of CPAN which she missed in Hackage was standardized changes files. It seems to me that one way to acheive this would be to add a --changelog flag to sdist (or maybe make default). This call 'darcs changes' and copy into the ChangeLog everything up to 2 tags ago. (2 tags because the first tag might be you preparing for a release). I'd imagine parsing would be dead easy: 'lines' to split it up into individual entries, and then take until you hit a 'tagged' entry. If the resulting list is length of 1, then take again. So you'd go 'runhaskell Setup sdist --changelog', and ChangeLog in the tarball would have, say, for Monadius: ---- Wed Feb 20 18:37:42 EST 2008 gwern0(a)gmail.com tagged 0.91 Wed Feb 20 18:37:29 EST 2008 gwern0(a)gmail.com * misc improvements: newtype, cabal, fmt Fri Dec 7 16:23:53 EST 2007 gwern0(a)gmail.com * rm extra source-files The line was originally there because there is an icon for Monadius in the source-files and some sort of Windows resource text file telling Windows to use it; I'm removing the mention of them in the .cabal because I don't think Cabal handles that right now. Thu Dec 6 16:30:31 EST 2007 gwern0(a)gmail.com * whitespace changes, add haskell98 to dependencies Tue Dec 4 13:46:38 EST 2007 gwern0(a)gmail.com * mv cabal field so hackage doesn't complain Tue Dec 4 13:10:47 EST 2007 gwern0(a)gmail.com * cabal fixes Tue Dec 4 08:32:25 EST 2007 gwern0(a)gmail.com tagged 0.91 ---- At this point, Hackage could be updated to link to it in the same way as it does for the .cabal file. That way, people could then easily take a look and see what's new since the last version. (Said facility is currently a little difficult unless the package authors manually maintain a ChangeLog and specifically include it into the tarball; you'd still have to either go to the repo or download the tarball simply to find out what's different from the older packages.) --gwern -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/244> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 14

[Hackage] #216: need a way to specify the foreign libraries a package depends on
by Hackage 22 Dec '09

22 Dec '09

#216: need a way to specify the foreign libraries a package depends on ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: major | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ----------------------------------+----------------------------------------- Package descriptions allow one to specify which Haskell libraries a package depends on, but foreign ones. Designing something that can be used with native package managers is complicated because many of them alter the upstream library names in unpredictable ways. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/216> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

[Hackage] #171: Add command to automagically create an initial cabal package
by Hackage 18 Dec '09

18 Dec '09

#171: Add command to automagically create an initial cabal package --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Linux | --------------------------+------------------------------------------------- Don Stewart has a nice tool called mkcabal (http://www.cse.unsw.edu.au/~dons/code/mkcabal/) which creates an initial cabal package. It would be nice to have this built into the 'cabal' program itself so that "cabal create" or "cabal init" or similar would interactively create a cabal package. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/171> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #261: Marking packages deprecated
by Hackage 05 Nov '09

05 Nov '09

#261: Marking packages deprecated ----------------------------+----------------------------------------------- Reporter: nibro | 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: | ----------------------------+----------------------------------------------- There should be a way to mark a package as '''deprecated''' so it doesn't show up on the main Hackage listing. If a newer package, with the same name, is uploaded then the older packages will in effect be defunct. But if you don't have a newer package with the same name, there is currently no way to "get rid of" packages that are no longer valid. There may be several reasons for why you would want to do this, likely most often because the contents of the package are superceded by functionality in some other package, with a different name. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/261> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #282: profiling versions of libraries not managed well
by Hackage 30 Sep '09

30 Sep '09

#282: profiling versions of libraries not managed well ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: profiling Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ At the moment, if you want profiling builds of libraries which you have already installed, the only way to get them is to unregister and rebuild with profiling turned on. This is especially inconvenient when you have a program that depends on many different libraries... Ideally, I could just add a flag to rebuild a program with profiling, regardless of whether I'd installed profiling versions or not... Any ideas on how this should be managed? What configurations should be allowed? How do we make sure the same library version is used for the profiling build as was used for the normal build? When do we just give up and make the user figure it out? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/282> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7