Automagic cabalising of projects?
Donald Bruce Stewart
dons at cse.unsw.edu.au
Mon Nov 20 02:59:07 EST 2006
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 at 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
More information about the cabal-devel
mailing list