So, on the joy of functional infrastructure. As previously discussed at the cafe, there's a bit of a plan to make a cabalising wizard. Yesterday I hacked up a quick tool[1] to do 2 things: [1] http://www.cse.unsw.edu.au/~dons/code/mkcabal/ 1) create a stub cabal file: $ runhaskell ../mkcabal.hs Project name: haq What license ["GPL","LGPL","BSD3","BSD4","PublicDomain","AllRightsReserved"] [BSD3]: BSD3 Created Setup.lhs and haq.cabal $ ls Setup.lhs haq.cabal $ cat haq.cabal Name: haq Version: 0.0 Description: Project description License: BSD3 License-file: LICENSE Author: Author Name Maintainer: user@email.address Build-Depends: base Executable: haq Main-is: Haq.hs $ cat Setup.lhs #!/usr/bin/env runhaskell > import Distribution.Simple > main = defaultMain 2) create a stub project repo, including cabal files and readmes $ runhaskell ../mkcabal.hs --init-project Project name: haq What license ["GPL","LGPL","BSD3","BSD4","PublicDomain","AllRightsReserved"] [BSD3]: Created new project directory: haq $ ls haq $ cd haq $ ls Haq.hs LICENSE README Setup.lhs haq.cabal Neil et al have suggested that the core should be abstracted out as a library, in order to write clients. This is a good idea. I'm interested, oh Ancient and Justified Developers of the Cabal, about where this should go. Should the tool try to fill in more details? If so it should probably be part of the cabal distro and use the existing cabal library. Should it stay lightweight? Should it try to discover the project src tree? Should it suggest hierarchical names to use? How can we make this most useful? Do people know of package wizards for other infrastructure that works well? What plans for automagic cabalisation have people been thinking about. Cheers, Don