Re: [Haskell-cafe] Hackage - MacPorts?
On Wed, Sep 3, 2008 at 10:14 PM, John MacFarlane [EMAIL PROTECTED] 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? I seem to remember that Eric Kidd started working on something like this at the Hackathon in Freiburg. /Björn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage - MacPorts?
On Wed, 2008-09-03 at 17:54 -0400, David Menendez wrote: On Wed, Sep 3, 2008 at 4:14 PM, John MacFarlane [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage - MacPorts?
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage - MacPorts?
On Thu, 2008-09-04 at 12:09 -0400, David Menendez wrote: On Thu, Sep 4, 2008 at 5:19 AM, Duncan Coutts [EMAIL PROTECTED] 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. Ducan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage - MacPorts?
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 [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage - MacPorts?
On Thu, Sep 4, 2008 at 4:14 PM, Don Stewart [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage - MacPorts?
dave: On Thu, Sep 4, 2008 at 4:14 PM, Don Stewart [EMAIL PROTECTED] 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. Well, if you develop with GHC, then you can just use the native packages. 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. We unregister the old packages, and you need to reinstall them. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage - MacPorts?
On Thu, 2008-09-04 at 20:08 -0400, David Menendez wrote: On Thu, Sep 4, 2008 at 4:14 PM, Don Stewart [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage - MacPorts?
On 2008 Sep 4, at 20:08, David Menendez wrote: 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. MacPorts has the same problem with Perl (XS code is dependent on the exact version), and they don't seem to have put nay effort into fixing it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hackage - MacPorts?
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? John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage - MacPorts?
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. One possible plan I have is for cabal-install to be a lib and a tool because there's a lot of useful code in there that these tools could re-use and share. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage - MacPorts?
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage - MacPorts?
On Wed, Sep 3, 2008 at 4:14 PM, John MacFarlane [EMAIL PROTECTED] 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. -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
