# from John Peacock
# on Wednesday 02 December 2009 11:05:
>Sounds like you need something like a metafile for each plugin (a mini
>manifest) which M::B can use to resolve which plugin is needed at that
>point.
Perhaps, but I was saying that this info should be provided as part of
the Build.PL contents (or analogous to that -- or otherwise benignly
supplied during new()) so that what plugins we need at any given stage
is declared by the module author. As I see it, this only needs to be
super-thoroughly checked at `Build dist` time -- where we ensure that
plugins on the "big 3" actions are in the dependency list. The rest of
the errors could be handled well enough with runtime messages.
>Would those meta files be included in the M::B bundle or be
>available at a well-known location (e.g. CPAN)? The former requires a
>lot more cooperation if multiple authors are generating plugins. The
>latter requires net access during the install
If by "the M::B bundle" you mean the developer's distribution tarball
and not the Module-Build distribution, then yes. But otherwise, no I
wouldn't try to maintain a central source of this stuff because then
we're back to playing gatekeeper not to mention more stuff to maintain.
I don't think plugins need to be heavily managed -- they just need to
give the module developer enough hooks to do the right thing. Trying
to do the right thing on the developer's behalf is going to tend to get
in the way more than it's worth.
>...at $WORK ...resolve which library to load. It only needs to be
>enough to get to the point of knowing what package to load, then allow
>the plugin itself to register options, etc, and continue from there.
>So by having these two stages, you can go back to "plugin configures
>itself" after M::B decides whether to load it at all...
But see my example where the 'release' action is provided entirely by a
plugin. We don't want to try to load that unless the release action is
run and we will never need it on an installation-target machine. So,
I'm wanting that sort of "conditional laziness" in plugin loading plus
error messages which are only a hair beyond "just good enough for a
professional to read and understand".
--Eric
--
The opinions expressed in this e-mail were randomly generated by
the computer and do not necessarily reflect the views of its owner.
--Management
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
