On Monday 04 August 2008, Eric Wilhelm wrote:
> # from Shlomi Fish
>
> # on Monday 04 August 2008 04:14:
> >> 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.
>
> Just write some code that does what you want to do. I recommend that it
> is neither a patch nor a subclass.
>
> #META.in.yml
> add_to_cleanup:
> - Math-Vec-*
> - META.yml
> create_makefile_pl: passthrough
> dist_version_from: lib/Math/Vec.pm
> license: perl
> module_name: Math::Vec
> test_requires:
> Test::More: 0
>
>
> # Build.PL
> ...
> use YAML;
> my $builder = $build_class->new(
> %{YAML::LoadFile('META.in.yml')},
> );
>
> Done?
Well, ideally, I won't need to repeat this functionality for each and every
M::B I write. But yes, it seems OK.
> Of course there's the hang-up that not all build parameters turn
> into META.yml, so it would be nice to have some parallels between them
> instead of needing to put a meta_merge in your META.in.yml.
I don't understand this paragraph.
>
> There is the problem of now needing configure_requires => YAML, but you
> might as well since patching Module::Build::YAML to support Load()
> would just mean adding a configure_requires for a newer M::B.
Ah.
>
> The point is to minimize the barrier to installation without being
> totally bored as an author, so maybe just have a Build.PL.in template
> and a tool to instantiate the Build.PL.
>
> $template =~ s/^\s*# PARAMETERS GO HERE.*$/$params_string/m;
>
Oh! You mean generate the Build.PL from "Build.PL.in". Hmmm....
> Obviously, not all dependencies can be static - thus the Build.PL and
> the dynamic_config flag. But your tool could certainly just conjure a
> stock Build.PL boilerplate if it doesn't find a Build.PL.in file.
It's hard for me to follow you.
>
> We've also talked about a META.local.yml file as a way for the installer
> toolchain to have a more uniform handling of dynamic_config => 1.
>
> In theory, I could set dynamic_config => 0 in my META.yml and quit
> shipping a Build.PL file, right? Ah well, one can dream.
>
> By the way, saying "because I want to" is a terrible answer to "why?".
> Perhaps you hove some reason like being able to automate module
> publishing, simplifying input data, or eliminating troubles with stale
> templates.
I've discussed it in the classification tool here - http://xrl.us/bi6n9 .
Namely, I want a GUI tool to edit the tags and categories of the CPAN
distribution. So I need it to provide them as input to Build.PL, while not
analysing and modifying Build.PL itself (which is close to impossible), and
while being able to do sanity checks on the tags+categories before it is
released (so the distro's publisher won't be screwed up) and while providing
a nice and usable interface for that (as opposed to editing text files by
hand which is error prone and hard to interact with the outside world).
> I've probably had 2-3 episodes of hacking together some
> shell and perl translations to my Build.PL files (of which there are
> 60+ in my checkouts dir atm.)
WDYM by "Shell and Perl translations"?
Regards,
Shlomi Fish
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
What Makes Software Apps High Quality - http://xrl.us/bkeuk
Shlomi, so what are you working on? Working on a new wiki about unit testing
fortunes in freecell? -- Ran Eilam
