Automagic cabalising of projects?
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
dons@cse.unsw.edu.au (Donald Bruce Stewart) writes:
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.
This is pretty cool! Does it go through and find . -name "*.hs" in order to fill out the exposed-modules field and what-have-you? Does it search for "module Main" to find the binaries? Just some ideas.
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.
I think it should live separately from Cabal, just for the sake of modularity, but it could depend on the Cabal package. With Hackage, people could install it easily enough, and I like to encourage layered tools rather than building things monolithically. Helps us make better interfaces.
Should it stay lightweight? Should it try to discover the project src tree? Should it suggest hierarchical names to use?
Generally, I'd try to keep it lightweight if I were you. You get a lot of value right away, but the more you add, the fewer people it will Just Do The Right Thing for. You could have High, Medium, and Low levels of prompting, depending on how much the user wants to fill in the fields later. Low would be just the required fields, I guess.
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.
Sounds good.
How can we make this most useful? Do people know of package wizards for other infrastructure that works well?
There's one for Debian that's OK, though it's not really a wizard. It doesn't prompt you for anything.
What plans for automagic cabalisation have people been thinking about.
Not much that I can remember. peace, isaac
participants (2)
-
dons＠cse.unsw.edu.au -
Isaac Jones