ralsina:

On Wednesday 20 August 2008 13:15:29 Loui wrote:

...

On Wed, Aug 20, 2008 at 09:09:48AM -0700, Don Stewart wrote:

...

10 weeks after the Arch Haskell group started, there are now 500 Haskell packages bundled up for Arch.

I've written about how we automated the construction of Arch packages from Haskell Cabal format, via the cabal2arch tool, and a small survey of 10 nice packages from the set, here,

http://cgi.cse.unsw.edu.au/~dons/blog/2008/08/21#the_500

Cheers, Don

Nice. Maybe AUR should be rewritten in Haskell too. Ha Ha.

Is anyone interested on a similar approach to Python's PyPI? It sounds like a fun project!

The main Haskell package index, Hackage, much like PyPI, has just been rewritten using HAppS (http://happs.org/) -- it'll be going live soon. -- Don

ralsina:

On Wednesday 20 August 2008 13:34:57 Don Stewart wrote:

...

ralsina:

...

On Wednesday 20 August 2008 13:15:29 Loui wrote:

...

On Wed, Aug 20, 2008 at 09:09:48AM -0700, Don Stewart wrote:

...

10 weeks after the Arch Haskell group started, there are now 500 Haskell packages bundled up for Arch.

I've written about how we automated the construction of Arch packages from Haskell Cabal format, via the cabal2arch tool, and a small survey of 10 nice packages from the set, here,

http://cgi.cse.unsw.edu.au/~dons/blog/2008/08/21#the_500

Cheers, Don

Nice. Maybe AUR should be rewritten in Haskell too. Ha Ha.

Is anyone interested on a similar approach to Python's PyPI? It sounds like a fun project!

The main Haskell package index, Hackage, much like PyPI, has just been rewritten using HAppS (http://happs.org/) -- it'll be going live soon.

Sorry, I miswrote!

I meant "apply something similar to this to Python's PyPI, so Arch gets a bunch of python packages" ;-)

Ah, I see. Well, I wrote a little bit about what makes it feasible. Basically, a clear package dependency spec, that doesn't rely on runtime initialisation. Following the model of the cabal2arch tool might just work. -- Don

Why not? It just takes a few keen hands, and some time (: Few months ago when I was learning Python I built quite a bunch of them from PyPi but they never made it into unsupported because it was one huge mess. How about a VCS repo alongside the binary offering? Call it the PyArch project. Or ArchPy. Or Pytharchoras....

ralsina:

On Wednesday 20 August 2008 14:09:14 Ray Rashif wrote:

...

Why not? It just takes a few keen hands, and some time (: Few months ago when I was learning Python I built quite a bunch of them from PyPi but they never made it into unsupported because it was one huge mess.

How about a VCS repo alongside the binary offering? Call it the PyArch project. Or ArchPy. Or Pytharchoras....

I think I will give a try this weekend. Building a PyPI package for Arch is trivial, and reading the dependency info is very easy, so I will just try to do it.

If it works... great. If it doesn't... then we start again with more hands :-)

For what it's worth, I think the principle of "more automation, less hands" is worth following. If you do it right, no human intervention will be needed. Looking at the design of cabal2arch, http://code.haskell.org/~dons/code/cabal2arch/Main.hs It has to do a few things. But if you get those right, it's hands off: * Have a canonical name for each haskell library dependency. i.e. Cabal -> haskell-cabal * Have a lookup table to map C libraires to their Arch package names translationTable = M.fromList [("Imlib2", "imlib2") ,("SDL", "sdl") ,("alut", "freealut") ,("bz2", "bzip2") ,("cblas", "blas") ,("crack", "cracklib") ,("crypto", "openssl") ,("curl", "curl") ,("freetype", "freetype2") ,("glib", "glib2") ,("wmflite", "libwmf") ,("il", "devil") ,("jpeg", "libjpeg") .... * And remember what Haskell dependencies are installed by default, and can be omitted from the build system. So, basically, parse the source spec file, and construct a data type representing the PKGBUILD, data PkgBuild = PkgBuild { arch_pkgname :: String , arch_pkgver :: Version , arch_pkgrel :: !Int , arch_pkgdesc :: String , arch_arch :: ArchList ArchArch , arch_url :: String , arch_license :: ArchList License , arch_makedepends :: ArchList ArchDep , arch_depends :: ArchList ArchDep , arch_source :: ArchList String , arch_md5sum :: ArchList String , arch_build :: [String] , arch_install :: Maybe String , arch_options :: ArchList ArchOptions } The job is then to just tranlsate the native package format into this structure, and pretty print the result. Most of the tedium is in maintaining the list of Arch names for C libraries. -- Don