Shipments in Cabal

Isaac Jones ijones at syntaxpolice.org
Fri Dec 9 14:50:03 EST 2005


"Simon Marlow" <simonmar at microsoft.com> writes:

> 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


More information about the Libraries mailing list