Disclaimer: the name is a "working title". You don't even have to buy
the naming rights to change it.
# from Ken Williams
# on Monday 23 October 2006 07:35 pm:
>I'd like to pick up this thread again if possible. Splitting out a
>set of developer's tools from the installer's tools is something I'd
>really like to see happen.
Sorry that my "tomorrow" was so terribly delayed. I haven't gotten an
implementation yet, but I have thought about how to make things work in
an installer environment.
use inc::builder;
# maybe some options or something here
my $build_class = builder('Module::Hack');
my $builder = $build_class->new(...);
$builder->create_build_script;
in inc/builder.pm
# this code is autogenerated by Module::Hack
sub builder {
my ($package) = @_;
eval("require $package") or return('Module::Build');
return($package);
}
That's basically it for install-side implementation. The autogenerated
code would be created with `./Build incbuilder` just like manifest and
etc.
The basic ideas have been written down at this point at:
http://scratchcomputing.com/svn/Module-Hack/trunk/
(see lib/Module/Hack.pm and lib/Module/Hack/Manifesto.pod)
There's still a few issues to work out.
1. Making sure that your code builds in the absence of Module::Hack. I
think that any problems here are the developer's own fault. We'll talk
about install-side plugins later. If you're overriding ACTION_install
and can't add a build_requires entry, I can't help you there.
2. We lose the democratization of "the installer is the development
tool." I'm not sure this is a huge deal. Once you get over the hump
of installing M::B, installing M::H is easy on any modern perl. We
might need to add 'dev_requires' to META.yml, but I can think of at
least a few projects where this would be useful.
3. One might want to mix-n-match features from various M::B plugins. I
don't currently have a plan for compactly expressing this, but maybe
traits would do the trick. Most people trying to do `./Build dist` can
decipher an error message well enough to understand that they should
`cpan foo` to make it work, so maybe $self->want('foo') at runtime in
ACTION_blah is good enough for syntactic sugar and/or helpful errors.
I'm thinking the current dev features should be left in M::B as-is for
now, possibly making noise about deprecation if M::H needs to become
incompatible in some way.
Maybe builder() would be a simple dispatcher
# this code is autogenerated by Module::Hack v0.0.2
sub builder {
my $package = shift;
eval("require $package") or return('Module::Build');
# yeah, $package->VERSION >= $foo, etc would be a good idea
$package->import(@_);
return($package);
}
So, if you have directives for bring in traits...
my $build_class = builder('Module::Hack', traits => ['MatchMyPod']);
...
Then I guess what you get back is not Module::Hack, but an autogenerated
"Module::Hack::0x814ec28" (having methods from the MatchMyPod trait
flattened into it.) That might be over-engineered unless somebody
needs two unique trait collections where traits are incompatible, but
it's not that difficult to create Module::Hack::1, Module::Hack::2,
Module::Hack::3 packages keyed to caller() by a class hash. Note: you
can still subclass it.
As for installer-side plugins, what's wrong with build_requires =>
{Module::Hack => 0.1, Module::Build::Plugin::Foo => 0, ...} ? Yeah, we
might run into compatibility issues with new-fangled features and
dependencies, so maybe Module::Build::Plugins plus Module::Hack would
be in order (one providing the install-side compatibility and being in
build_requires, the other using Moose and such crazy stuff and being in
dev_requires.)
Credit (or blame) where due:
Michael Schwern played devils advocate on many items and brought up the
issue of istaller-side plugins, reminded me of the great equalizer,
etc. David Wheeler suggested that Module::Build::Plugins would be a
much better name.
That's about all I've got at the moment. Deadlines are currently
rushing past at an alarming rate.
Thanks,
Eric
--
"It is a mistake to allow any mechanical object to realize that you are
in a hurry."
--Ralph's Observation
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
