Re: [RESEND] Machine-Manipulatable Arguments for Module::Build

Hi!

On Monday 04 August 2008, David E. Wheeler wrote:
> 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.
>

OK, sounds fair.

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

Parse and modify Build.PL

> It generates META.yml, which can be 
> parsed. 

META.yml can be parsed, but if I modify it, then the modifications will be 
lost the next time I run Build.PL.

> End of story. (Oh, and BTW, Adam Kennedy put the lie to "only 
> Perl can parse Perl" myth.)

The problem is that even after I have a syntax tree in PPI, the programmer is 
capable of confusing the code enough so that knowing what exactly to modify 
will be hard. See, for example:

http://en.wikipedia.org/wiki/Halting_problem

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

<<<< I can name the Module::Build instance in any way I want>>>>

This means I can do:

{{{{{{{{{
my $mb = Module::Build->new(....);
}}}}}}}}}

Or:

{{{{{{{{
my $builder = Module::Build->new(....);
}}}}}}}}

Or:

{{{{{{{
my $foobar = Module::Build->new(....);
}}}}}}}

Etc.

<<<I can put some of the parameters in variables>>>

{{{{{{{{{{{
my @keywords = (qw(moose mouse oop omgponies));

 .
 .
 .

my $mb = Module::Build->new(
	meta_add =>
	{
		keywords => \@keywords,
	},
);

}}}}}}}}}}}

Now where do we need to change it?

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

So you agree that I should not edit META.yml directly? In this case I want 
something machine-readable as input to M::B, which will eventually end up at 
META.yml where the CPAN interfaces can find it.

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

Ah. But if I want to make it machine-readable, then I'll need a YAML (or 
whatever) file which will in turn be read by Meta-Build.PL which will run 
Build.PL with all of these command line args. This will add more complexity, 
and will be probelamtic if someone runs Build.PL directly.

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

Because I want to 

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

META.yml is intended for reading and is the exclusive domain of Build.PL to 
output. One cannot manipulate it directly and expect it to be preserved after 
running Build.PL again.

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

Ah. But I need to remember to append them to Build.PL everytime. If it's 
written in a file somewhere under the local directory it would be less 
error-prone.

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

See above.

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

I think I can accomplish that using a sub-class, so that will be my first 
lead. I'll also do it TDD-style, so you can understand what I mean using the 
tests.

Regards,

	Shlomi Fish

-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Why I Love Perl - http://xrl.us/bjn88

I met a guy in the bar, talked to her and she gave me her phone number.