Multi-library/package support for cabal

Hi all, Given that I'm often quite annoyed by the almost-total lack of support for developing a set of coherent libraries together in a convenient fashion[1] using Cabal, I'd like to ask a) are there any current plans or GitHub issues on implementing any support for this workflow that I should be aware of? b) are there any wiki pages (or similar) detailing any requirements that people might have for this type of workflow? c) would there be *interest* in somebody (e.g. me) implementing support for such a workflow? d) if "yes" to c), how should one go about it? What kind of consensus needs to gathered and whom do I need to convince of the brilliance of this idea? I should note that I have *very* little experience with Cabal/cabal-install's code (a couple of pretty trivial patches, I think), but it's Haskell, so how bad could it be, right? I have a week's vacation coming up next week (and probably a few more a little later in the summer), and I think I may be able to dedicate quite a bit of time to getting this done, *but*... if I'm going to spend that time, I want something that can be integrated into cabal-install *and* I want something that has a reasonable chance of actually getting merged. (Of course, I don't expect bad code to be merged, but I'm quite happy to fix bad code whenever it's pointed out to me.) Otherwise, I'll just keep using cobbled-together one-off Python scripts (and terribly inefficient workflows)... and complaining constantly about it :). So... how can get this ball rolling? Regards, [1] E.g. I have a set of cqrs-* libraries + demo executable packages in a single git repository, each with their own subdirectory and .cabal file. These libraries may depend on each other in arbitrary non-circular ways and I want to be able to conveniently build all of it in the appropriate order and with a consistent set of dependencies in a single sandbox.

On 06/19/2015 08:14 PM, Bardur Arantsson wrote:
Hi all,
[--snip--] Oh, yes, I should add. I've been thinking about a couple of approaches for how to achieve this ("UI-wise" so to speak) and would like some "guesstimate" of feasibility by people in the know. 1st approach: Use a single cabal file to describe a full set of libraries (and executables) and perform dependency resolution over the whole set, thus hopefully at least ensuring internal consistency. Some sort of shorthand would perhaps be useful to avoid having to specify common dependencies and version bounds redundantly. I could imagine Hackage would have issues with this, but if anyone who knows more about Hackage internals could chime up...? I guess it might be possible to "split" such a meta-.cabal file into smaller files for upload to Hackage -- if nothing else then to avoid backward-compatibility issues. 2nd approach: Some sort of meta-tooling which could gather up multiple cabal files, create a single sandbox and resolve dependencies for all subprojects in a single step. Probably easier to implement, but less elegant. A general observation: In either case we want the compile/install step to report errors and warnings consistently. At least my current hobbled-together Python script uses the ability to do "cabal install [flags] dir1 dir2 dir3 ...", but this means that you miss out on warnings in many cases since warnings for dependencies aren't printed by default for "install". These are the kinds of annoyances that I want to avoid. Regards,

On Fri, Jun 19, 2015 at 1:14 PM, Bardur Arantsson
Hi all,
Given that I'm often quite annoyed by the almost-total lack of support for developing a set of coherent libraries together in a convenient fashion[1] using Cabal, I'd like to ask
a) are there any current plans or GitHub issues on implementing any support for this workflow that I should be aware of?
There are two that I am aware of. [1] is very similar to one of your workflows. [2] is related, but centers around improving the interaction between sandboxes and multiple packages, and less on the actual workflow of managing multiple packages simultaneously. [1]. https://github.com/haskell/cabal/issues/1367 [2]. https://github.com/haskell/cabal/issues/2631
c) would there be *interest* in somebody (e.g. me) implementing support for such a workflow?
Yes, definitely!
d) if "yes" to c), how should one go about it? What kind of consensus needs to gathered and whom do I need to convince of the brilliance of this idea?
If what you have in mind is like #1367, I would say that consensus has already been reached.
I have a week's vacation coming up next week (and probably a few more a little later in the summer), and I think I may be able to dedicate quite a bit of time to getting this done, *but*... if I'm going to spend that time, I want something that can be integrated into cabal-install *and* I want something that has a reasonable chance of actually getting merged. (Of course, I don't expect bad code to be merged, but I'm quite happy to fix bad code whenever it's pointed out to me.)
I think there is some overlap with #2631, so I would suggest chiming in there to avoid duplicating efforts. This is a frequently requested feature; I think the chances of anything you write *not* being merged are very, very small. -- Thomas Tuegel

On 06/19/2015 08:59 PM, Thomas Tuegel wrote: [--snip--] Thank you, I'll have a thorough look at everything you pointed out tomorrow. Likewise for anyone else who'd care to chime in! :) Regards,

Hi Bardur,
https://github.com/haskell/cabal/issues/2004 is another bug that seems like
it could be related. The idea is to use a single sandbox across multiple
packages so if you have a directory layout like
top/
application/
library1/
library2/
If you were to then:
cd top, cabal sandbox init, cd library2, cabal install, cd ../library1,
cabal install, cd ../application, cabal install
The packages library1, library2 and their dependencies would all be
installed in the sandbox in top and the cabal install inside the
application directory would resolve dependencies from that sandbox. Each
folder would still maintain its own cabal configuration so global analysis
wouldn't be possible (or on the other hand, necessary).
On Fri, Jun 19, 2015 at 12:03 PM, Bardur Arantsson
On 06/19/2015 08:59 PM, Thomas Tuegel wrote: [--snip--]
Thank you, I'll have a thorough look at everything you pointed out tomorrow. Likewise for anyone else who'd care to chime in! :)
Regards,
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
-- Love in Jesus Christ, John Alfred Nathanael Chee http://www.biblegateway.com/ http://web.cecs.pdx.edu/~chee/
participants (3)
-
Bardur Arantsson
-
John Alfred Nathanael Chee
-
Thomas Tuegel