[Haskell-cafe] package maintainers: updating your packages to work with GHC 6.8.1
Duncan Coutts
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)
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Henning Thielemann
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
_______________________________________________
Haskell mailing list
Has...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Duncan Coutts
> 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
Henning Thielemann
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?
Simon Marlow
> 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
Henning Thielemann
Splitting of the base package seems to have invalidated the links from
HaskellWiki into the Library documentation.
Thomas Schilling
> Splitting of the base package seems to have invalidated the links from
> HaskellWiki into the Library documentation.
And Hoogle. Try searching for "Set" ...
Neil Mitchell
> And Hoogle. Try searching for "Set" ...
I'm already aware about Hoogle, and will endeavour to fix it up tomorrow.
Thanks
Neil
brad clawsie
> 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"?
Duncan Coutts
> 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 Coutts
> 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