ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garima Bathla <garima.bat...@gmail.com>
Subject feature request: configuration intersections only implemented halfway
Date Wed, 29 Jul 2009 18:10:42 GMT
I've come to the conclusion that the new configuration intersections feature
is implemented only halfway, and as a result it presents an inconsistent,
misleading, confusing contract. Either we yank it out from Ivy entirely or
we implement it fully.

Suppose I have an Ivy module called system with configurations like so:
<configurations>
 <conf name="windows" grouping="platform" />
 <conf name="linux" grouping="platform" />
 <conf name="release" grouping="quality" />
 <conf name="debug" grouping="quality" />
</configurations>

Plus publication artifacts like so:
<publications>
  <artifact name="art1" type="dll" conf="windows,release" />
  <artifact name="art1d" type="dll" conf="windows,debug" />
  <artifact name="art1" type="so" conf="linux,release" />
  <artifact name="art1d" type="so" conf="linux,debug" />
</publications>

Suppose I have an Ivy module called consumer with a dependency on system
like so:
<dependency … conf="default->windows+debug" />

Now, this + notation is allowed by Ivy, thanks to the configuration
intersections feature. However, according to system's ivy.xml, this
windows+debug syntax is useless and meaningless. The implicit request for
art1d.dll could just as well be expressed as:
<dependency … conf="default->windows,debug" />

Why? Because art1d.dll is being published in the union, so if you want
art1d.dll, then you should just ask for the union. (Never mind that, if you
only consider only the configurations and not the publications to be the Ivy
module's interface, then the fact that art1d.dll is being delivered via the
union should be encapsulated from the consumer.) Anyway, if you ask simply
for the union, you'd also get art1.dll and art1d.so, which you don't want.
So now you're having to delve into what the particulars of the publication
artifacts (again, violating idea of configurations being the interface and
encapsulating publications) to try to divine something that is not
explicitly there.

Worse, what if the creator of the system Ivy module really did want the
unions to work as unions? Asking for intersections is an attempt to undercut
the interface offered by the dependency module. There's nothing about the
following interface (to the extent that publication artifacts can be
considered an interface) to suggest that intersections are involved—unless
you're really, really clever at reading between the lines:
<artifact name="art1" type="dll" conf="windows,release" />
<artifact name="art1d" type="dll" conf="windows,debug" />
<artifact name="art1" type="so" conf="linux,release" />
<artifact name="art1d" type="so" conf="linux,debug" />

What if you were really, really clever though? You could divine that, "Hey,
look at all those combination patterns. You could make intersections out of
them." Wow, though, that's complicated.
Here's what bothers me about this contract as a senior enterprise developer.


We put a premium on programming languages' ability to express constructs in
as simple, expressive, and intuitive a manner as possible. But when you get
right down to it, Ivy too is a language. Or to be precise, Ivy provides a
general-purpose language for transitive dependency management/artifact
retrieval. In that context, Ivy should strive to express dependencies in as
simple, intuitive, and expressive a manner as possible. It's our instinct as
developers to make sure we're no less smart than the next guy, to try to
understand anything, no matter how complex, that gets thrown at us. But in
the course of trying to understand complexity, we tend to lose sight of when
complexity becomes needless. In today's world, we don't use Roman numerals
so that we can bask in our cleverness, we use decimals so we can get the job
done. The implicit intersection contract above is too complicated.

So again, let's either implement configuration intersections fully or remove
configuration intersections entirely from Ivy. What we have now is a
confusing, complicated compromise that suggests that we couldn't make up our
minds about this feature.

You can tell where I stand on that either/or. I want configuration
intersections implemented fully, and that means simply that the + notation
should be allowed on artifact confs, like so:
<artifact name="art1" type="dll" conf="windows+release" />
<artifact name="art1d" type="dll" conf="windows+debug" />
<artifact name="art1" type="so" conf="linux+release" />
<artifact name="art1d" type="so" conf="linux+debug" />

I can absolutely attest that I have a real-world business case that doesn't
involve cute pets or cute coffee drinks where, if I'm not able to express
something like "windows+release" on a publication, I'm stuck between a rock
and a hard place:
·    Rock: If I'm forced to create combination Ivy confs like
"windows-and-release", my Ivy module descriptors become totally
unmaintainable really fast.
·    Hard place: If I have to rely on consumer Ivy modules knowing to
express their dependencies using "windows+release" (with all the
communication that involves), then whenever a consumer Ivy module mistakenly
does "windows,release", my deployment is hosed.

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".

Someone might also argue that intersections are too restrictive and will get
too few artifacts. And to that I say, restrictiveness is the whole point.
Who is anyone but the module publisher to know what is too restrictive?

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.

Still, I'm sympathetic to that argument. And I think the ideal solution
would be to acknowledge that Ivy confs, as originally conceived, are not
composite constructs; so we need to introduce composite elements that can be
used to construct confs. Frankly, though, I'd rather not wait for the ideal
solution.

I'm hoping it's not too late for the simple fix of allowing + notation on
artifact confs to get incorporated into Ivy 2.1 before its final release.
And since the JIRA issue IVY1093 is not yet resolved, I'm thinking this
change would be a natural fit to just incorporate into that fix.

I will be more than happy to open a JIRA issue for this problem, but I
definitely will like to know your opinion on this before I do open one.

Regards,
Garima.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message