[Module::Build] You underestimate the problem

[Adam K. <ad...@ph...>]

Grr, stupid mailing list.

I can subscribe to it, but it's not sending me messages.

 > As long as it's a mini-language that can be parsed safely, then having
 > some expressiveness is fine.  Most of where this will crop up is in
 > module dependencies anyway, and the number of variables there is
 > relatively contained:
 >
 > * platforms (in some set)
 > * perl versions (in some set of ranges of versions)
 > * module versions (in some set of ranges of versions)

I think you underestimate the problem.

Firstly, define "platform". Is it the processor arch? The string in $^O? 
If it's 'Win32' then which Win32? Win95? Win98? What if I have a 
dependency that needs something specifically on Windows XP only. Or only 
works for Server versions of Win32.

What about environment variables?

There are already modules that add extra dependencies if 
$ENV{AUTOMATED_TESTING} is true, so that under testing they can do more 
thorough tests than would normally be done.

Then there's optional dependencies based on installed programs.

Module::Signature looks for the binary program 'gpg'. If it cannot find 
it, it adds an extra 20 modules to the dep chain.

What version of Perl? 5.6 with threads, without threads?

So you need branch logic, you need to interact with the environment 
outside of the process (at least in a read-only manner) so you can't 
sandbox whatever is running the logic, you probably need a full range of 
boolean logic operators, which means you also need precedence support, 
and you are probably going to want subsections (i.e. subroutines) and 
probably inclusion of other files for reuse (i.e. modules) and you will 
inevitably want something like loops. Also, some of these are going to 
be host-specific, so you STILL can't run them anywhere but the current 
machine.

You just can't fit the richness required into a data structure, which 
means you can't fit it into META.yml.

The alternative of a mini-language is dangerous. I've seen the only one 
proposed so far and it is a very heavy language.

With META.yml on one side (data) and Makefile.PL on the other (code) I 
have trouble seeing that you can find ANY place in the middle that is 
usefully complete. I'd love to be convinced otherwise, but I'd like to 
see someone demonstrate a WORKING solution that can handle even the 
Bundle::CPAN subset of module before you commit to incorporating it.

 > Use case: Create an index of all dependencies for all distributions on
 > the Win32 platform without running Makefile|Build.PL for all
 > distributions.  (E.g. for a potential "CP-PAN" i.e. "CamelPack-PAN")

There is no such thing as a single fixed "Win32 Platform". That's not to 
say it isn't possible under some extremely tight controlled conditions, 
just that it doesn't exist in the real world that CPAN applies to.

If someone were to come up with a suitably framed bet, I'd probably be 
willing to put down serious money to say it is unsolvable.

In Perl, dependencies are ultimately programmatic. You can only 
approximate the dependencies in advance in an advisory way. Which is 
what we do already in META.yml.

Adam K