duncan.coutts:

On Wed, 2008-09-03 at 13:14 -0700, John MacFarlane wrote:

...

It would be great if there were an automated or semi-automated way of generating a MacPorts Portfile from a HackageDB package, along the lines of dons' cabal2arch. Has anyone been working on such a thing? And, are any haskell-cafe readers MacPorts committers?

Whoever starts on this should not start from scratch. We now have several of these tools so there's lots of code to look at but ideally we should be sharing more code.

It seems the front end of cabal2arch -- general parsing and processing of .cabal files, would be reusable in any tool. foo.cabal url | v Parsed cabal file | v Resolved dependencies/flags | v Normalised for Arch | v Translated into ArchPkg ADT | v instance Pretty ArchPkg | v foo.tar.gz native Arch package. You just have to define a data structure for the target output, and a pretty printer instance, and any platform specific dep differences. -- Don

On Wed, 2008-09-03 at 17:54 -0400, David Menendez wrote:

On Wed, Sep 3, 2008 at 4:14 PM, John MacFarlane wrote:

...

It would be great if there were an automated or semi-automated way of generating a MacPorts Portfile from a HackageDB package, along the lines of dons' cabal2arch. Has anyone been working on such a thing? And, are any haskell-cafe readers MacPorts committers?

Gregory Wright handles the ports of GHC, alex, happy, haddock, and others.

In my experience thus far, MacPorts feels like a poor match for Cabal. As far as I can tell, you get at most one active installation of a given port, which means you can't use MacPorts to manage packages for multiple Haskell environments (GHC and Hugs, stable GHC and development GHC, etc.), and after a GHC upgrade, any installed Haskell packages will still be installed, even though the new GHC can't see or use them.

That's exactly the same situation as with Gentoo. We provide a ghc-updater program that re-installs all the existing libs for the new ghc. Gentoo also only provides libs for ghc. Duncan

On Thu, Sep 04, 2008 at 12:09:33PM -0400, David Menendez wrote:

Does anyone know whether arch linux and debian can handle multiple Haskell environments?

Debian currently only handles one version of GHC (but package dependencies mean that you can't end up with libraries compiled for the wrong version installed). There wouldn't be any technical problems embedding the ghc version in the package names, and /usr/bin/ghc would work fine with the alternatives system. I don't think that having multiple versions in Debian itself is feasible, but you could certainly do it in another repository. (technically, it's one version of ghc 6.*, as the package names use "ghc6" rather than just "ghc"). Having libraries for other implementations is fine in Debian, although most of the libraries are ghc6-only at the moment, I believe. Thanks Ian

duncan.coutts:

On Thu, 2008-09-04 at 12:09 -0400, David Menendez wrote:

...

On Thu, Sep 4, 2008 at 5:19 AM, Duncan Coutts wrote:

...

That's exactly the same situation as with Gentoo. We provide a ghc-updater program that re-installs all the existing libs for the new ghc. Gentoo also only provides libs for ghc.

That's more convenient than re-installing all the libs by hand. I guess that's good enough for non-developer use; someone who just wants to install a program doesn't need to have more than one version of GHC installed, for example. It pains me to see the assumption that Haskell = GHC built in to our distribution methods, though.

Yeah, I know. It's really a limitation of systems like Gentoo. Gentoo's position is that you should not encode things like this into the package name and provides a 'slotting' mechanism to allow multiple versions, however it's not quite expressive enough to slot on the haskell implementation and still get all the lib deps right.

...

RPM apparently handles this by having the library packages install themselves under new names that include the environment name and version. I assume Nix can handle multiple Haskell environments.

Right. And yes, Nix can do everything because it's jolly cunning and takes the functional/persistent approach.

...

Does anyone know whether arch linux and debian can handle multiple Haskell environments?

Debian does, again by encoding the haskell implementation name into the package name. I think arch only provides libraries for ghc.

That's right, on Arch we just go for what people actually need, i.e.: 1) 1 compiler, GHC 2) GHC comes with the core+extra set, so they're implicitly available 3) all other libs are "haskell-(map toLower packagename)" The complication to support multiple implementations et al isn't done by any other language group (i.e. libs aren't bundled for multiple python impls, or different C compilers), so I don't see why we should waste time on that either. Pragmatic, I know. -- Don

On Thu, Sep 4, 2008 at 4:14 PM, Don Stewart wrote:

That's right, on Arch we just go for what people actually need, i.e.:

1) 1 compiler, GHC 2) GHC comes with the core+extra set, so they're implicitly available 3) all other libs are "haskell-(map toLower packagename)"

The complication to support multiple implementations et al isn't done by any other language group (i.e. libs aren't bundled for multiple python impls, or different C compilers), so I don't see why we should waste time on that either. Pragmatic, I know.

So Haskell developers still have to manage everything themselves. That's probably reasonable. What happens when you upgrade GHC? The problem MacPorts has is that the libraries are still listed as installed, even though they are no longer registered or useable. -- Dave Menendez http://www.eyrie.org/~zednenem/

On Thu, 2008-09-04 at 20:08 -0400, David Menendez wrote:

On Thu, Sep 4, 2008 at 4:14 PM, Don Stewart wrote:

...

That's right, on Arch we just go for what people actually need, i.e.:

1) 1 compiler, GHC 2) GHC comes with the core+extra set, so they're implicitly available 3) all other libs are "haskell-(map toLower packagename)"

The complication to support multiple implementations et al isn't done by any other language group (i.e. libs aren't bundled for multiple python impls, or different C compilers), so I don't see why we should waste time on that either. Pragmatic, I know.

So Haskell developers still have to manage everything themselves. That's probably reasonable.

What happens when you upgrade GHC? The problem MacPorts has is that the libraries are still listed as installed, even though they are no longer registered or useable.

Gentoo provides a ghc-updater program that re-installs all the registered libraries for the new ghc. It's based off of a similar system used in Gentoo for managing major version upgrades in Python so perhaps MacPorts has something similar you could adapt. Basically it searches through the installed haskell packages to find the ones registered with the older compiler and then works out what order to re-install them in and then does it. So it's not fully automatic as users have to run this program manually after upgrading ghc, but it's not too painful. Duncan