Re: [Module::Build] You underestimate the problem

[Ken W. <ke...@ma...>]

On Apr 25, 2006, at 8:17 AM, Adam Kennedy wrote:

> Grr, stupid mailing list.
>
> I can subscribe to it, but it's not sending me messages.
>

Next time I see sourceforge I'll kick them.


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

We would use the list of $^O strings and os_type() values found in  
Module/Build.pm .

>
> What about environment variables?

Out of scope.

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

Which is a bad idea.  They'd handle that using dynamic_config, though.

>
> Then there's optional dependencies based on installed programs.

Out of scope for this iteration, maybe for a future iteration.

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

Then it would have to use dynamic_config in this iteration of our  
mini-language.

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

dynamic_config.


We've got a set of predicates that we *know* are going to be useful.   
Let's not let the perfect be the enemy of the good here - we don't  
need to define the entire universe of helpful predicates before we  
make some of them available to users.


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

That's untrue, of course - perl code itself can be thought of as a  
data structure (the parse tree), or else things like your PPI would  
be impossible.

What we're saying is that our data structure semantic doesn't need to  
be (and shouldn't be) Turing-complete.


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

It's anything for which Module::Build->os_type() eq 'Windows'.

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

Nobody's claiming we'll solve the world's dependency problems  
completely, but we know we can do better than we do now.

  -Ken