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 => [EMAIL PROTECTED], }, ); }}}}}}}}}}} 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.
