Hello Python Community. I bring greetings from the Haskell community (http://www.haskell.org) ;) There has been a lot of discussion of late about creating a grand-unified build & distribution system for "3rd party" Haskell libraries (those not distributed with the compilers). Python's Distutils has come up a few times. The Haskell Library Infrastructure Project's web page is just a wiki page which can be found here: http://www.haskell.org/hawiki/LibraryInfrastructure. I'm running this project. I also wear another hat in that I'm interested in maintaining Debian packages related to Haskell, so I want to make my job easier by 1) writing software support, and 2) making it easy for other people to maintain Debian packages so I don't have to :) I've read much of the documentation at http://www.python.org/sigs/distutils-sig/doc/. I've also made a toy Python program that uses distutils. It occurs to me that the issues that were facing the Python community are strikingly similar to those facing the Haskell community now, except perhaps for the fact that there are at least 3 very strong Haskell "compilers" that we want to support. One idea for this distribution system, which we're calling the Library Infrastructure Project, is to create a nice gmake-based build system, document it, and leave it at that. Another idea is to use a Haskell-based Distutils type system. Now I think that the Haskell-based system should work out-of-the-box for pure-haskell modules (no extensions), and maybe wrap a more complex make-based system where necessary (as when interfacing with C or using preprocessors). I definitely want to optimize for the common case of joe-haskell-programmer wanting a nice way to distribute modules to his friends, but of course I also want to allow Haskell developers to do more complex things. The main issues facing us are: 1) there are a variety of Haskell "compiler" implementations, one of which is an interpreter :) 2) not all Haskell implementations are available on all architectures (ghc for instance) 3) just about every Haskell "compiler" and release is binary-incompatible, (except maybe for nhc98). That is, if we were going to distribute binary libraries, we'd need different binaries for ghc4, ghc5, and ghc6. Also we'd need different binaries for profiling versions of the libraries, etc. For instance, if I were to create a binary package HUnit, which is a simple case since its pure Haskell code, I would need: hunit-{hugs,nhc98} hunit-ghc{4,5,6} hunit-ghc{4,5,6}-prof And whenever a new version of GHC6 is released (for instance), all of the packages like hunit-ghc6 would need to be updated at the same time. That doesn't even get into the issues of the wide variety of preprocessors that are common in this rapidly advancing language[1]. So all of this suggests to me that we want to keep a global list of installed libraries and recompile them whenever a new Haskell "compiler" gets installed. This is why I want an abstraction layer above make. So I want to ask you if you can think of any obvious things we should watch out for if we try to do something similar to what Python is doing. Also, there was some mention (in the related "summary of the Developer's Day session") of Python's distutils creating a Makefile and wrapping calls to make, is this what you're doing? Do you / did you find yourself duplicating a lot of what make already does, ie dependencies, etc, or do you utilize make? What about configuration, do you typically interface with autoconf somehow, or does distutils have its own way to figure out configuration details? Is a typical distutils setup.py program pretty much like what we see in the example documentation? The developer provides some meta-data and gets a distribution tool? Is there any support for more complex stuff like interfacing with external systems? Does distutils handle dependencies? I've hacked together something that creates a source tarball and a basic Debian package from a Haskell version of the distutils-type metadata. I can make that available in a few days if anyone is interested. peace, isaac [1] Haskell is designed to have a "stable" version, Haskell98, and the compilers come with a variety of extensions so that it is very useful as a research language as well.