Eric Wilhelm wrote:
Note that we can't use a more typical "plugin configures itself" approach (e.g. call the plugin's init() method after loading) because M::B needs to run on installation targets where a dev plugin might not be available and in other cases we need to have enough info to automatically declare dependencies or perhaps even handle bundling. But the plugins probably need to still declare something about what they provide so the loader can double-check against what is in Build.PL.
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. 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 (which probably should not be considered to be an absolute blocker in this day and age).
We do something like this at $WORK so that the config system can 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...
John
