May 2013 - cabal-devel

Hackage 2 trustees
by Erik Hesselink 11 Sep '13

11 Sep '13

Hi all, I just upgraded our internal hackage to the latest HEAD. I found that the behavior of the 'trustees' group has changed. Previously, they could upload any (existing) package, but that doesn't work anymore. This functionality was very useful for us, since otherwise, we'd have to add all our coders as maintainers to all our packages. I've patched our local code, but my question is: * Is this a bug and should I push a patch? * Is this intended and should I push a patch to the text at http://hackage.typlab.com/packages/trustees/, since it doesn't correspond to the current behavior? Regards, Erik

2 1

darcs patch: Add a new checkout Command (and 1 more)
by Joachim Breitner 20 Jul '13

20 Jul '13

Hi, the small feature implemented by the attached patches could make it more convenient for people to quickly and easily contribute to hackage packages. Do you want me to open a ticket for this or can you appl yit right away? Thanks, Joachim 2 patches for repository http://darcs.haskell.org/cabal-install: Sun Nov 7 12:35:32 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Add a new checkout Command Given a package name, this uses the SourceRepo field of the newest versionf of that pacakge to figure out the repository location and calls the right VCS invocation. Sun Nov 7 12:43:35 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Add a --dry-run flag to cabal checkout

2 3

ANNOUNCE: haskell-packages-0.1
by Roman Cheplyaka 27 May '13

27 May '13

I am happy to announce the first release of haskell-packages. http://haskell-suite.github.io/haskell-packages/ There are two cases when you may need haskell-packages: if you are writing a Haskell compiler (or any tool that processes Haskell source code, such as a static analyzer), or if you want to integrate with an existing Haskell compiler that uses haskell-packages. ## Writing a compiler If you are writing a compiler, you typically want to integrate it with Cabal, to be able to build ordinary Haskell packages. If you go the hard way, this involves: 1. **Parsing command line parameters**. Sounds easy — just take a list of files to compile. In reality you also need to handle package ids and package dbs, CPP options (`-DFOO=1`), language extension flags (`-XRankNTypes`) etc. To integrate with Cabal, you also need to tell it the list of installed packages, supported languages and extensions etc. 2. Actual **integration with Cabal** means understanding how Cabal works and hard-coding support for your compiler. And then getting it accepted and waiting for the next Cabal release. You may pretend that you are GHC or other compiler that is already supported by Cabal. It might work, but often it won't, for various reasons. Also, GHC's command line protocol is quite complex. 3. **Package management**. You need to implement a package db mechanism, which would let you to keep track of installed packages. Then you'd have to implement a `ghc-pkg`-like tool to manage those databases, for both Cabal and your users. **Or**, you can simply use this library! It already has command line options parsing, Cabal support, and package management. All you need to do is to provide the function to do actual compilation and tell a couple of other things about your compiler. See the `Distribution.HaskellSuite.Compiler` module for details. ## Using other compilers Some compilers produce artifacts that you may want to use. A good example is the `gen-iface` compiler from haskell-names which generates an *interface* for each module — the set of all named entities (functions, types, classes) that are exported by that module. This information can be then used either by other compilers, or by tools like IDEs. Assuming the compiler uses haskell-packages and exports its database type, it's very easy to use its artifacts. See `Distribution.HaskellSuite.Packages` for package resolution and `Distribution.HaskellSuite.Modules` for module resolution. ## Installation Note that haskell-packages uses (yet unreleased) haskell-src-exts 1.14. Get it [here][hse]. It doesn't matter what Cabal version you use together with haskell-packages, but if you want to invoke a haskell-packages compiler from Cabal (see [Usage](#usage)), you need to build our [fork of Cabal][Cabal]. Eventually it will be merged into Cabal. [hse]: https://github.com/haskell-suite/haskell-src-exts [Cabal]: https://github.com/feuerbach/Cabal ## Usage To compile a Haskell package using a haskell-packages tool: cabal install --haskell-suite -w $TOOL where `$TOOL` may be either a full path to the compiler, or just an executable name if it's in `$PATH`.

1 0

Re: [Haskell-cafe] How to throw an error if using "cabal-install" < version XYZ?
by Ryan Newton 23 May '13

23 May '13

Great! Thanks. I adapted that trick and it worked fine: https://github.com/rrnewton/haskell-lockfree-queue/blob/cb8ca1a5d8b4c02e45e… On Wed, May 22, 2013 at 11:53 PM, Carter Schonwald < carter.schonwald(a)gmail.com> wrote: > Hey Ryan, > I ran into a related issue, heres a a way you can do this safe IN the > cabal file (or at least you can modify my hack for your purposes) > > heres a link to the workaround I did for making LLVM-hs work across >= > 1.17 and < 1.17 cabal, but you could abuse it to make sure setup.hs barfs > on old cabal > https://github.com/bos/llvm/blob/master/base/Setup.hs#L89-L116 > > heres a quick one off gist that takes my trick and does something helpful > for you variant + makes sure the tool can't build otherwise > > https://gist.github.com/cartazio/5632636 > > I just wrote a snippet that you can just add to your setup.hs and it > should guarantee the setup.hs will barf with a helpful error message on > cabal < 1.17.0 > > > On Wed, May 22, 2013 at 10:50 PM, Ryan Newton <rrnewton(a)gmail.com> wrote: > >> A cabal-install bug <https://github.com/haskell/cabal/issues/1284> was >> fixed recently that pertains to building C libraries with profiling. >> >> As a result, I want a certain package<http://hackage.haskell.org/package/atomic-primops-0.1.0.2>to test if cabal-install < 0.17.0 is used, and throw a preemptive error. >> Otherwise this package fails in weird ways at runtime (it's a nasty one). >> >> I noticed with some surprise the following sequence: >> >> * $ cabal --version* >> * cabal-install version 1.16.0.2* >> * using version 1.16.0.3 of the Cabal library* >> * $ cabal clean* >> * $ cabal install* >> * $ cat dist/build/autogen/cabal_macros.h | grep VERSION_Cabal* >> * #define VERSION_Cabal "1.17.0"* >> >> Alright, so that, in retrospect, makes sense. The version is which *my* >> library is linked with is the relevant one, not the one cabal-install was >> linked with [1]. >> >> So the natural next thought is to move the MIN_VERSION_Cabal test into >> Setup.hs, and force cabal to use it by setting the build type to Custom. >> But... I just learned from this ticket that the cabal macros are not >> available in Setup.hs: >> >> http://hackage.haskell.org/trac/hackage/ticket/326 >> >> Uh oh, what's left? >> >> -Ryan >> >> [1] P.S. Personally I'm now using a bash function like below, to force >> the two versions to be the same: >> >> function safe_cabal_install () { >> VER=`cabal --version | tail -n1 | awk '{ print $3 }'` >> cabal install --constraint="Cabal==$VER" $* >> } >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >

1 0

How to throw an error if using "cabal-install" < version XYZ?
by Ryan Newton 23 May '13

23 May '13

A cabal-install bug <https://github.com/haskell/cabal/issues/1284> was fixed recently that pertains to building C libraries with profiling. As a result, I want a certain package<http://hackage.haskell.org/package/atomic-primops-0.1.0.2>to test if cabal-install < 0.17.0 is used, and throw a preemptive error. Otherwise this package fails in weird ways at runtime (it's a nasty one). I noticed with some surprise the following sequence: * $ cabal --version* * cabal-install version 1.16.0.2* * using version 1.16.0.3 of the Cabal library* * $ cabal clean* * $ cabal install* * $ cat dist/build/autogen/cabal_macros.h | grep VERSION_Cabal* * #define VERSION_Cabal "1.17.0"* Alright, so that, in retrospect, makes sense. The version is which *my* library is linked with is the relevant one, not the one cabal-install was linked with [1]. So the natural next thought is to move the MIN_VERSION_Cabal test into Setup.hs, and force cabal to use it by setting the build type to Custom. But... I just learned from this ticket that the cabal macros are not available in Setup.hs: http://hackage.haskell.org/trac/hackage/ticket/326 Uh oh, what's left? -Ryan [1] P.S. Personally I'm now using a bash function like below, to force the two versions to be the same: function safe_cabal_install () { VER=`cabal --version | tail -n1 | awk '{ print $3 }'` cabal install --constraint="Cabal==$VER" $* }

2 1

Hackage2 does not always read the package category properly
by Henk-Jan van Tuyl 22 May '13

22 May '13

L.S., I found, amongst others, the SDL package (at page http://new-hackage.haskell.org/packages/ ) in the Unclassified category, while the cabal file of this package says "Foreign binding". On page http://new-hackage.haskell.org/package/SDL , clicking on the link "Foreign binding", leads to the top of the package listing, instead of the Foreign binding section. Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

1 0