On Wed 2009-07-29 at 11:10h, Garima Bathla wrote on ivy-user: : > Now, someone might argue, "It's ambiguous how configuration > intersections affect transitive dependencies." And I say to that, > not so. It would be easy enough to do a logical proof that > configuration intersections like "windows+release" would behave no > differently than manufactured composite configurations like > "windows-and-release".
Consider a diamond-shaped dependency where the module with these "windows" and "release" confs is the transitive dependency (= the "tip" of the diamond). Now imagine the left side of the diamond depends only on "windows", while the right side depends only on "release". It's clear that the "bottom" of the diamond will receive both the artifacts of "windows" and of "release", but will they get your "windows+release" artifacts? Should they? How does it interact with configuration intersections of dependencies? Is this compatible with Ivy's resolution algorithm? These issues don't arise with a "windows-and-release" dependency. As for configuration intersections used as a conf for retrieving, the problem there is that with "windows+release" you need to somehow combine the conf mappings for "windows" and "release". Suppose that for some dependency M you have "windows->foo" and "release->bar". Which of the artifacts of the configurations "foo" and "bar" of dependency M should be retrieved for "windows+release"? Either you take the union of "foo" and "bar", which would contradict the intent of getting an intersection, in particular if the bulk of the artifact payload resides in the dependencies. Or you actually take the intersection, which is likely to cause trouble, because only the maintainer of M knows whether such an intersection of "foo" and "bar" makes any sense (it probably doesn't), and even this he only knows for the publications of M proper, not for the artifacts of the dependencies of M -- same problem as with the original module. And then there's the aspect of multiple dependencies. Should the intersection be taken here too? Should it matter whether artifacts come from two different configurations of the same dependency, as opposed to coming from two different dependencies? (I don't think it should.) It's clear that with multiple dependencies no one really knows whether intersections of the artifacts from those dependencies make any sense. > Someone might also argue that intersections are too restrictive and > will get too few artifacts. In your use case of an "intersection artifact", i.e. an artifact that is only applicable when some combination of configurations is requested, the requester actually gets more artifacts than when requesting each configuration separately. But I guess you were referring to configuration intersections as dependencies here. > And to that I say, restrictiveness is the whole point. Who is anyone > but the module publisher to know what is too restrictive? Well, he doesn't know what is too restrictive for the modules he depends on, exactly because only the publishers of those modules can know that -- though actually they can't if they have dependencies themselves. Intersections simply don't work for dependencies. The root reason for this is that dependencies are defined on the level of modules and configurations, not on the level of artifacts, and hence its not possible to determine the actual dependencies of arbitrary subsets of artifacts like the ones created by configuration intersecions. > There is one counterargument I am sympathetic to. If the configurations > section of a module descriptor is considered the Ivy module's sole > interface, then configuration intersections, as something that would be > expressed only in the publications section, are not part of the interface. > But that train has already left the station. If we allow configuration > intersections on dependencies, then we're already expressing a request that > goes beyond the configurations section; we're already saying we've taken a > peek at the publications section. Yes, that's why I think it's unsound. A client module shouldn't depend on whether an artifact comes from a direct dependency or from a transitive dependency. For example one should be able to create a "virtual" module that has no publications, but just depends on other modules, such that the effect of depending on the virtual module is the same as directly depending on those other modules. Or, a module should be able to decide to "outsource" some of its artifacts into a dependency, without this breaking any client modules. The only way to achieve this equivalence in the presence of intersections is for the intersections to be applied transitively, which, as pointed out above, cuts across the declared dependencies of the modules. -- Niklas Matthies
