On Aug 3, 2008, at 05:19, Shlomi Fish wrote:

> Hmmm... that's interesting. Sounds useful. Is it supported in
> search.cpan.org/kobesearch yet? Of course, I'd also like to have
> Freshmeat-like categories:
>
> http://freshmeat.net/browse/18/

You would need to get them into the META spec, I think.

> Because "The only thing that can parse Perl is perl". It would be  
> very hard to
> write a third-party program that will parse a typical Build.PL  
> syntax and
> manipulate it along with all the possible edge-cases. For example,  
> in some of
> my modules I have used a sub-class of Module::Build (which I called
> Test::Run::Builder) instead, so if I'm looking for Module::Build I  
> won't find
> it.

Um, nothing has to parse Build.PL. It generates META.yml, which can be  
parsed. End of story. (Oh, and BTW, Adam Kennedy put the lie to "only  
Perl can parse Perl" myth.)

> Similarly, I can name the Module::Build instance in any way I want  
> which will
> further complicate things. Or I can put some of the parameters in  
> variables,
> etc.

I don't follow you here.

> Yes, but if I over-ride the paramaters in META.yml, then it will be
> over-written once I re-run Build.PL. META.yml is entirely at the  
> mercy of
> Build.PL and should not be edited by hand.

Correct.

> I want to allow a program or a human to give parameters to Build.PL  
> so they'll
> eventually be preserved there.

You can pass parameters to Build.PL quite easily: via the command-line.

> No, it's not. Build.PL places some other parameters into META.yml,  
> like the
> individiuals .pm files and their versions, etc. We need a way to  
> input it
> paraemeters in a way that's not hard-coded in the Build.PL Perl code.

Why?

>> I find Perl easier to type than YAML. YAML is much more error-prone,
>> IMO.
>
> Yes, but computer programs can more easily read and write YAML.

Hence META.yml.

> Well, I'm not proposing that we completely do away with Build.PL or  
> even with
> the parameters given to the Module::Build constructor. I'm just  
> saying that
> we should give a way for programs to give it arguments as well,  
> without
> having to parse the Perl and try to make sense of it.

Yep, that's what the command-line arguments are for.

> So we have the machine+human-manipulatable input and the data and  
> code in the
> Build.PL as input to Module::Build.

I'm pretty sure you can already do what you want via command-line  
arguments. If some are not properly passed through, well then you can  
patch that, that seems reasonable to me. And I could see a case for a  
Module::Build::Config or something that uses a configuration file to  
call Build.PL and pass it parameters (See SVN::Notify::Config for an  
example of a third-party module that uses YAML to replace command-line  
options to another program). It's entirely possible I'm missing your  
point, but it sure seems like you can pretty much already do what you  
want to do, without requiring any new features in Module::Build.

But a patch demonstrating what you want would probably be more  
convincing, in that we could much better understand what it is you want.

Best,

David