package maintainers: updating your packages to work with GHC 6.8.1
If you maintain a Haskell package this is for you. So now that GHC 6.8.1 is out you'll want to test your package with it. We'd especially like maintainers of packages that are distributed on hackage.haskell.org to test their packages and update them as necessary. However we would appreciate it if your packages will still work with GHC 6.6.x, so read below for details on how to do that. You'll most likely find that your package fails to build with GHC 6.8.1 with an error message like this: Could not find module `Data.Map': it is a member of package containers-0.1.0.0, which is hidden. This is the first symptom of the change in the base library in GHC 6.8.1. Several parts of the old base library got split out into separate packages. For example Data.Map is now in the containers package. Unfortunately this means most packages need updating. Of course you'd also like to make your packages continue to work with GHC 6.6.x (and perhaps older). If you go and just add containers to your package's build-depends then it will no longer work with GHC 6.6.x or older. So the solution at the moment is to use Cabal configurations like so: flag splitBase description: Choose the new smaller, split-up base package. library if flag(splitBase) build-depends: base >= 3, containers else build-depends: base < 3 Since this uses a new Cabal feature you'll have to make your packages require Cabal-1.2 or later: cabal-version: >=1.2 This is ok since Cabal-1.2.x comes with ghc-6.8 and can also be installed from hackage for older ghc versions. For a bigger example see Cabal's own .cabal file: http://hackage.haskell.org/packages/archive/Cabal/1.2.2.0/Cabal.cabal The new Cabal syntax is explained in the Cabal user guide: http://haskell.org/cabal/release/rc/doc/users-guide/x30.html#configurations This is all explained in more detail on the wiki: http://haskell.org/haskellwiki/Upgrading_packages And the details of other api changes in the libraries are in the GHC 6.8.1 release notes: http://haskell.org/ghc/docs/6.8.1/html/users_guide/release-6-8-1.html A list of packages on hackage that currently fail to build with GHC 6.8.1 is here: http://www.haskell.org/pipermail/libraries/2007-November/008529.html We realise that this change is rather disruptive, requiring changes in each package. We've started a wiki page with ideas on how to avoid this in future when the base package is shrunk again. http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility Duncan (Cabal release manager)
On Mon, 5 Nov 2007, Duncan Coutts wrote:
If you maintain a Haskell package this is for you.
So now that GHC 6.8.1 is out you'll want to test your package with it. We'd especially like maintainers of packages that are distributed on hackage.haskell.org to test their packages and update them as necessary. However we would appreciate it if your packages will still work with GHC 6.6.x, so read below for details on how to do that.
Maybe this is also an opportunity to merge Categories: Xml (generic-xml) -> XML data structures (hgal) -> Data Structures Code generation (harpy) -> Code Generation network (infinity) -> Network
On Mon, 2007-11-05 at 03:12 +0000, Duncan Coutts wrote:
If you maintain a Haskell package this is for you.
flag splitBase description: Choose the new smaller, split-up base package. library if flag(splitBase) build-depends: base >= 3, containers else build-depends: base < 3
By the way, if you have several common deps it's perfectly ok to factor them out like this: Flag splitBase Description: Choose the new smaller, split-up base package. Library Build-Depends: network, HTTP, HTTP-Simple, MissingH, time>=1.1.1 if flag(splitBase) Build-Depends: base >= 3, containers else Build-Depends: base < 3 In a future version of Cabal we might have this nicer syntax: Library Build-Depends: base, network, HTTP ,HTTP-Simple, MissingH, time>=1.1.1 if package(base >= 3) Build-Depends: containers Duncan
On Mon, 5 Nov 2007, Duncan Coutts wrote:
By the way, if you have several common deps it's perfectly ok to factor them out like this:
Flag splitBase Description: Choose the new smaller, split-up base package.
Library Build-Depends: network, HTTP, HTTP-Simple, MissingH, time>=1.1.1
if flag(splitBase) Build-Depends: base >= 3, containers else Build-Depends: base < 3
In a future version of Cabal we might have this nicer syntax:
Library Build-Depends: base, network, HTTP ,HTTP-Simple, MissingH, time>=1.1.1
if package(base >= 3) Build-Depends: containers
When Cabal development started I suggested to use Haskell code as configuration file, because there will be much extensions and the package description will not fit into a simple syntax soon. This suggestion was rejected because the Package description should be readable by an IDE. With the flags and package version comparison we move quickly to a Turing complete scripting language in form of a package description. :-) Btw. does the Setup.hs script still serves a purpose?
On Mon, 2007-11-05 at 12:47 +0100, Henning Thielemann wrote:
When Cabal development started I suggested to use Haskell code as configuration file, because there will be much extensions and the package description will not fit into a simple syntax soon.
So of course there is a trade-off to be made in the expressiveness of the language used for package descriptions & build procedures. My experience with build systems (and as a gentoo packager I've seen quite a few) tells me that a full turing complete language gives developers too much rope with which to hang themselves. Developers make packages which work on their systems; they cannot be expected to test in lots of different environments. So inevitably platform-specificisms creep in because there is no easy way to check for their absence (you'd have to actually go and build on a dozen different platforms). With a less expressive language that hides platform details there is more wiggle room for the packaging system to interpret the package in a way that makes sense for different platforms. The one place we do have general Haskell code in in Setup.hs files. I've seen quite a few of these now and almost every single non-trivial Setup.hs is wrong in some respect. They work in the normal case on the developers machine but fail when building a distro package (where the build and install steps are separated) or would fail on windows or a myriad of other things. By contrast when we have some bug in Cabal on some platform we can fix it in one place, not in the Setup.hs file of every single package.
This suggestion was rejected because the Package description should be readable by an IDE. With the flags and package version comparison we move quickly to a Turing complete scripting language in form of a package description. :-)
It's pretty important that it never gets there :-).
Btw. does the Setup.hs script still serves a purpose?
Some, but as little as possible. I'd expect only 10% of the most complex packages will need to use them in future. Duncan
Splitting of the base package seems to have invalidated the links from HaskellWiki into the Library documentation.
On Mon, 2007-11-05 at 15:42 +0100, Henning Thielemann wrote:
Splitting of the base package seems to have invalidated the links from HaskellWiki into the Library documentation.
And Hoogle. Try searching for "Set" ...
On Mon, Nov 05, 2007 at 11:35:11AM +0000, Duncan Coutts wrote:
By the way, if you have several common deps it's perfectly ok to factor them out like this:
Flag splitBase Description: Choose the new smaller, split-up base package.
Library Build-Depends: network, HTTP, HTTP-Simple, MissingH, time>=1.1.1
if flag(splitBase) Build-Depends: base >= 3, containers else Build-Depends: base < 3
these look suspiciously like the deps to my own module that i uploaded last night to be in compliance for 6.8.1! thanks for cleaning it up duncan and in the future i will follow this example. a slight aside - why are .cabal files not "in haskell"?
On Mon, 2007-11-05 at 07:55 -0800, brad clawsie wrote:
On Mon, Nov 05, 2007 at 11:35:11AM +0000, Duncan Coutts wrote:
By the way, if you have several common deps it's perfectly ok to factor them out like this:
Flag splitBase Description: Choose the new smaller, split-up base package.
Library Build-Depends: network, HTTP, HTTP-Simple, MissingH, time>=1.1.1
if flag(splitBase) Build-Depends: base >= 3, containers else Build-Depends: base < 3
these look suspiciously like the deps to my own module that i uploaded last night to be in compliance for 6.8.1!
Yep :-) Who needs a release announcement when there's the hackage RSS feed? http://hackage.haskell.org/packages/archive/recent.rss
thanks for cleaning it up duncan and in the future i will follow this example.
a slight aside - why are .cabal files not "in haskell"?
It's a slightly long story, but basically not being turing complete means the description can be read and interpreted according to context, not just executed. Afterall, we don't just want to install packages, we also want to translate them into native packages. Duncan
Duncan Coutts wrote:
flag splitBase description: Choose the new smaller, split-up base package. library if flag(splitBase) build-depends: base >= 3, containers else build-depends: base < 3
This is also a good time to add upper bounds to dependencies, in accordance with the package versioning policy: http://haskell.org/haskellwiki/Package_versioning_policy For instance, with accurate dependencies the above would become flag splitBase description: Choose the new smaller, split-up base package. library if flag(splitBase) build-depends: base >= 3.0 && < 3.1, containers >= 0.1 && < 0.2 else build-depends: base >= 2.0 && < 3.0 Cheers, Simon
participants (6)
-
brad clawsie -
Duncan Coutts -
Henning Thielemann -
Neil Mitchell -
Simon Marlow -
Thomas Schilling