On Thursday 26 October 2006 3:38 pm, Eric Wilhelm wrote:
> >With MB, having to subclass in order to add-in new features to the
> > build works great, except that it doesn't let me split out those
> > features into something that I can easily re-use from one project to
> > the next.
>
> What good timing. Did you see my mail about Module::Hack?
> http://www.nntp.perl.org/group/perl.module.build/422
Did, and thought that the timing was just about right. :)
> > use base qw( Module::Build::Pluggable );
> >
> > # then, load up MBP plug-ins
> > use Module::Build::Plugin::example;
> > use Module::Build::Plugin::...
> > use Module::Build::Plugin::...
>
> The trouble is that you have to have M::B::Pluggable for installation.
> This is certainly valid where the installer requires the plugins, but
> what about when the plugins are only for development or build dist?
Haven't run into that myself (yet), but you're right.... slurping in all of
the plugins like above would require that they be available any time you
wanted to do a build.
> use inc::builder;
> use base builder('Module::Build::Pluggable');
>
> Your base would then be Module::Build::Pluggable so long as that module
> is installed.
Right... but if its not installed, I may have parts of the build that just
don't work at all any more. Although I could forsee that some of the plugins
would be optional or required only for dev/testing, I'd also expect some of
them to be mandatory in order for the project to build correctly.
> Then of course your subclass needs to check whether that worked before
> requiring the plugins. Maybe
>
> if(__PACKAGE__->isa('Module::Build::Pluggable')) {
> require Module::Build::Plugin::example;
> }
>
> or something, but that drops the import. Might be better to do
>
> Module::Build::Plugin->import(
> plugins => [qw(
> Module::Build::Plugin::example
> Module::Build::Plugin::blah
> )]
> );
The second makes more sense.... less to write, and still painfully obvious
what it is we're trying to achieve. For brevity, maybe something like:
Module::Build::Plugin->import(
plugins => [qw( example blah My::Custom::Module )]
);
where by default it'd look under MB::Plugin, but if it didn't find it under
there it'd try it as a fully qualified package name.
> My main comment is that the plugins should only be needed where and when
> they are needed. Making sure we have them installed can be covered by
> requires, build_requires, and (hopefully) dev_requires.
Ah, ok... You're using "build_requires" to point out that "these plug-ins are
required in order to build", and other optional development plug-ins could
be "dev_requires" (and if they're not installed then it'd continue to march
along happily).
Out of curiosity.... do you have "inc::builder" yet? I'm thinking that we're
both approaching the same problem from two separate sides; I've focussed to
this point on getting the plugin framework together (and have a basic
prototype that loads and spits out dummy info), but I like you're "how it all
gets bootstrapped" idea better.
--
Graham TerMarsch
Howling Frog Internet Development, Inc.
