# from David Golden
# on Wednesday 02 December 2009 14:59:
>Anyway, when that's done, I think I'll have a clearer sense of what in
>M::B is really "core" and what is "author support". That said,
>plugins are probably not on my radar in the next year.
We can't really draw a line between "core" and "author support" -- only
between "core" and "not core" (because what was once in "core" is
expected to always be in "core".) Without plugins, there is not really
such a thing as "not core", which means nothing can depend on anything
and we have to program with twigs and string instead of Perl and the
CPAN. It would be convenient for many people if we added feature X and
Y to core, but we usually end up with something limited because of the
twigs and string, then you get even more mess when someone starts
copy+pasting subclass code with large swaths of M::B innards into
multiple dists.
So, of course the loading of plugins would maybe need to be core -- but
Module::Build::Plugins with configure_requires is probably feasible
(maybe even without monkey patching) given a bit of cooperation (or
just a bit of communication and not purposefully breaking the API.)
>Plus it auto-bundles itself in inc/. And Build.PL is just "use
>lib 'inc'; use Acme::Module::Build::Tiny".
I'm looking forward to seeing that without the bundling. This would
demonstrate that configure_requires and the "Build.PL command-line API"
is maturely supported in the toolchain.
--Eric
--
Issues of control, repair, improvement, cost, or just plain
understandability all come down strongly in favor of open source
solutions to complex problems of any sort.
--Robert G. Brown
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
