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
