2009/1/29 David Golden <[email protected]>:
> All that 'maybe_requires' indicates in META.yml is that these are
> requirements that may or not apply and that can only be resolved by running
> Build.PL or Makefile.PL.
I'm struggling to come up with many reasonable use cases for "maybe",
bearing in mind that we're going to overload "maybe" with every
possible different meaning, from "platform-specific dependency" to
"The PP version because you don't have a C compiler" to "You said you
wanted XYZ1234 support" to a hundred reasons we haven't thought of
yet.
There's a big risk of giving that flag more specific meaning that it
really means, in fact you did it yourself in the example.
> E.g. search.cpan.org could include them in a list 'related
> modules' or CPANTS could include them in determining what things are
> prerequisites of other things.
This updates the meaning of what might be an utterly critical
dependency on a Mac to merely a "related module". Saying that
something is "maybe" needed is really really vague, but that's about
as accurate as we can be.
I can see some advantages in splitting the list of modules needed in
100% of cases out from the set of modules needed in less than 100% of
cases when it comes to modelling the entire dependency graph in CPANTS
and other places, but only for our internal use.
Imagine the "maybe" dependency explosion of something like Jifty when
you look at it on the CPAN Dependencies page... it MIGHT install all
sorts of things. Does inflating the list of modules we show the user
by two or three times add any value? We gain some accuracy at the cost
of confusion and information overload. We can even say why they maybe
are needed.
I also note that once we get MYMETA.yml working, there's no reason we
can't have the CPAN Testers reports include them, which gets us a
reasonable percentage of the variations without having to reverse the
logic in every Makefile.PL.
Currently we can do
if ( case a ) {
requires Foo => 1;
requires Bar => 1;
}
if ( long calculation to test for a compiler ) {
requires Foo => 2;
requires Bar => 1;
} elsif ( case c ) {
requires Bar => 2;
requires This => 1;
requires Baz => 1.5;
} else {
requires That => 6;
}
Now we need to reverse all this logic
requires Foo => ( (case a) ? 1 : ( long calculation to test for a
compiler ) ? 2 : undef? );
requires Bar => ( (case a or long calculation to test for a compiler )
? 1 : (case c) ? 2 : undef );
requires Baz => ( (case c and not long caluclation to test for a
compiler ) ? 1.5 : undef );
requires That => ( (long calculation to test for a compiler and case
c) ? undef : 6 );
Maintenance of the dependency structure gets materially more difficult
for authors in exchange for getting the luxury of richer metadata, the
meaning of which is not easily explained to users without
misconceptions.
Adam K
