On Wed, Jan 28, 2009 at 8:48 PM, Adam Kennedy
<[email protected]>wrote:
> 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.
>
What if we called it "dynamic_requires" or something less vague than maybe.
The point being that these may or may not be required, depending on specific
configuration on a particular machine.
> 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.
>
Not necessarily only internal use. When pondering which of several similar
modules to use, I'll often look at META.yml to see requirements and get a
sense of what the dependency structure is, whether those modules are ones
that I'd choose to rely on and so on. Right now, I don't see the dynamic
ones -- I have to go troll through Build.PL or Makefile.PL and actually read
code. Seeing "maybe_requires" or "dynamic_requires" is useful information
in judging a module -- particularly for Win32 where things sometimes don't
work. If I saw a bunch of Win32::* modules in a 'maybe_requires' that would
signal that the author has actually thought about portability to Windows.
So I don't think it's just an internal use case.
> 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 specifically didn't give CPAN Dependencies as an example as I don't think
that's a useful place to include maybes. (Or it should be an optional
feature to show them.)
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
>
Oh, such lovely declarative logic. So much nicer than data structures. :-)
I don't think it *has* to be "maybe_requires( $module, $version, $condition
)" the way I original said. Perhaps maybe_requires( $module, $version ) is
equivalent to maybe_requires( $module, $version, 1 ). That would make long
if/else chains easier. So then you just have this:
if ( case a ) {
maybe_requires Foo => 1;
maybe_requires Bar => 1;
}
if ( long calculation to test for a compiler ) {
maybe_requires Foo => 2;
maybe_requires Bar => 1;
} elsif ( case c ) {
maybe_requires Bar => 2;
maybe_requires This => 1;
maybe_requires Baz => 1.5;
} else {
maybe_requires That => 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.
>
I don't want to add complexity for authors. So we agree there. And while I
understand that it's easy to assume that users are idiots, I think the
answer is to just try harder to write a definition that avoids
misconceptions.
It's not like we haven't faced a form of that before with "build_requires"
which means build *or* test requirements. Or, say, dynamic_config
defaulting to 1. ("Here's some meta information -- but by default you can't
trust it") :-)
-- David
