Hi, I'd recommend investigating using stack rather than cabal directly for this. Stack is good for a situation where you need to split things up into more than one .cabal file, and should be able to handle handle the dependencies between the modules without getting itself in a twist. By way of a non-solution, I'd also strongly recommend (from experience) not letting bitrot take hold over the course of the year and then putting all the effort in at the end to clean it all up at the end. If you're struggling to keep the Tax module in sync with the rest of the system, then that often indicates your dependencies are not quite right. For instance, it seems suspicious that tax calculations know anything about persistence. Hope that helps, David On 10 September 2015 at 19:26, Dimitri DeFigueiredo < defigueiredo@ucdavis.edu> wrote:

Yes, it's the classic diamond dependency graph. A / \ B C \ / D

A = Trader, B = ProfitCalculator, C = Persistence, D = MarketModel. It is not that I *want* Trader (A) to depend on two different versions of MarketModel (D), that is just a consequence. I don't have a choice.

What I want is for the ProfitCalculator (B) and Persistence (C) to always build. And if an update changes the MarketModel (D) from underneath them, they might break. So, I want them to each lock-in a specific version. In effect, I am forcing the graph above to turn into something like. A / \ B C / \ D D'

I may not write any code that uses the MarketModel (D) directly on the Trader (A). I do understand that there are at least 1 point to keep in mind: types defined in D will be different from those in D' (typeclasses will be defined twice)

But the benefit of *not* having to always keep everything building on the latest version every time I update the MarketModel (D) is huge for me!

Cheers,

Dimitri

Em 10/09/15 06:50, timmy tofu escreveu:

Using the 'cabal sandbox add-source' solution now requires that I

...

"add-source" the MarketModel package too. Otherwise, any change I make to this package will not be tracked.

then…

...

Cabal sets the paths for "import"ed modules in the "hs-source-dirs:" and that is global to the whole package.

I can't tell if you do or do not want ProfitCalculator and Persistence to track changes made in MarketModel.

If you do, and both should be in lock-step with it (unlike your situation with Tax), then you don't have a problem.

If not, then the problem is Trader would depend on ProfitCalculator which might depend on a different version of MarketModel than Persistence (upon which Trader also depends). That is a classic dependency problem and not a function of submodules or add-sourcing, per se. The Trader module seems to be at the top of this heap - why would you want the Trader to (indirectly) use one version of MarketModel through ProfitCalculator, and another through Persistence?

_______________________________________________ Haskell-Cafe mailing listHaskell-Cafe@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe