ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Matthies <ml_ivy-u...@nmhq.net>
Subject Re: feature request: configuration intersections only implemented halfway
Date Wed, 29 Jul 2009 20:16:48 GMT
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

Mime
View raw message