Shipments in Cabal

[Simon Marlow]

On 09 December 2005 19:50, Isaac Jones wrote:

> "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?

Yes.

> 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).

No, by "distrutable" I meant a source distribution, i.e. whatever it is
you grab from Hackage.

> 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.

That's a shame, I thought it was quite cool :-(  But I see your point.  

It seems slightly strange to be able to build *one* package using
Setup.lhs, but as soon as I need to split my package into two I have to
use some other tool to work on it.  Not a big deal though.

> 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.

Ok, but remember we're only solving a problem that occurs for developers
here.  Users don't need to know about search paths - they just need to
install a package and its dependencies.  A developer, on the other hand,
needs to be able to rebuild a set of packages in dependency order,
without building everything each time.  That is, the tool needs a way to
ask for a rebuild, not just a full configure/build/install.

And specifying the .cabal file for the metapackage isn't really enough:
you should really go through the Setup.lhs script (it might have some
optional dependencies, for example).

> 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.

Ok, I'm agnostic about depends.
 
> 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).

In-place usage is the main thing.  If we can agree on --packagedb that's
a step forward (simulating it with symlinks for Hugs?).  This is the
level that VS will hook into.

Then as long as we have a way to build a set of packages in dependency
order, without rebuilding everything each time, installing to a
temporary location, I think the non-VS developer's needs will be met
too.

[snip]

Cheers,
	Simon