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. On 09 December 2005 14:19, Krasimir Angelov wrote:
For the end user the presence of shipment isn't important. [snip] The shipment is more important for the developer.
yes, exactly what I said! [snip]
I will be lucky with Simon's proposal too. It will allow to build automatically all packages but I think that it is more complicated. At least everything that have to be added to Cabal for this proposal will be required in my proposal too. The aggregate package description is in fact just a replacement for the shipment description which Isaac proposed.
the point is that an aggregate package is just a package; we don't need a separate concept for it.
I don't think that it is required to have a separate description.
The problem with putting all the .cabal files in a single place is that you then have to distribute the whole set of packages together; and it becomes some kind of larger entity for which we need a name ("shipment"). Shipments will be visible at the Hackage level, because Hackage will have to know the set of packages contained in a shipment. I don't think we need to do this. All that is needed is an empty package that depends on all the others. Hackage doesn't need to learn anything new, neither do the other tools.
I have to write an another aggregate package. Will it be distributed separatelly in Hackage?
Yes - but that's exactly how other package systems work. It's flexible and simple. Cheers, Simon
"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
participants (2)
-
Isaac Jones -
Simon Marlow