On Mon 2008-03-31 at 19:24h, Xavier Hanin wrote on ivy-user: > On Mon, Mar 31, 2008 at 7:00 PM, Niklas Matthies wrote: : > > It's all fine (only) as long you control all the modules involved. > > But in that case, why wouldn't you simply specify these features > > globally for your build? > > Fine. And specifying globally for the build will somewhat be possible with > module descriptor inclusion: define a root module descriptor defining your > excludes, and include this descriptor in all your modules, and you're done.
Maybe I've been too subtle ;). I'm not asking for a new feature here. The root module descriptor usage is crystal clear to me, and it is obviously(?) the use case for which the features under discussion are being introduced/generalized, and yes of course it is covered by them. No dispute here whatsoever. What I was trying to get at - while trying not to step on anyone's toes - is whether these features, as currently envisioned (or already implemented), aren't actually harmful for the client side (= published Ivy file), and whether it wouldn't be worth reconsidering how they are implemented, rather now than later, to avoid having regrets later on when things can't be changed any more due to having to maintain backwards compatibility. As I wrote, it seems to me that having these features in published Ivy files breaks basic assumptions of Ivy's dependency model (such as the commutativity and associativity of conflict resolution) and is quite prone to lead to unintelligible and subtly changing resolution behavior in non-trivial scenarios. I was hoping for an exchange of ideas of how these features could be amended such that the problems mentioned above are avoided, while still satisfying the actual use cases. Just as an example, one possible way could be to disallow/not support these features in non-root modules during dependency resolution. I don't know whether that would fit the implementation, and wouldn't break any valid use cases, it's just an example of the kind of approaches I was aiming at. -- Niklas Matthies
