"Simon Marlow"
I just made some changes to my proposal:
http://haskell.org/hawiki/Cabal_2fAggregatePackages
Mainly I made it so that the sub-packages don't have to be in a subdirectory, this means it will be easier to tar up the aggregate package.
Can you clarify the terminology a bit? A distro package is an OS package? Like RPM? And a distributable is a kind of meta-package that does nothing but depend on other packages? (If so, let's call it a meta-package or something). I can't edit the wiki right now :( I like the idea of having a meta package that can be only dependencies, but I don't think I really like the --local idea. I don't really like the idea of one cabal package going to build another package, invoking another setup script. I think that should be left for layered tools. Although I'm all for adding flags to cabal to allow packages to be used in-place more effectively, I'd rather have a tool where I can say: cabal-install: metapackage/metapackage.cabal --searchpath=. and maybe cabal-sdist metapackage/metapackage.cabal --searchpath=. will go and build .tar.gz files for everything it can find. That way hackage won't have to change, it still works on the cabal-package level. Incidentally, we would need to separate the concept of depends and build-depends again, I guess. Remember that all build-depends cause -package flags to be added to the command line of GHC. If these dependencies are executables, then that's bad. Krasimir, would meta-packages and cabal-install solve the problems w/ visual studio? We could add flags to cabal to improve in-place usage, and to do something w/ a particular packageDB (though I want to figure out a way to solve this for Hugs too). We could have meta-packages which are just a minor refactoring of packages to say that they can just depend on other packages. This is definitely something that cabal needs anyway. We clean up the multi-executable thing, which never worked well anyway. But the actual handling of meta-packages should be left to layered tools like cabal-install. Cabal-get should be refactored to work on top of cabal-install; cabal-get should just download the packages and invoke cabal-install to do the dirty work. The nice thing about this solution is that if we need to add a shipment: field or some of these other suggestions, we can do it later and everything will still make sense. What do you guys think? peace, isaac