On Wed, Dec 2, 2009 at 6:17 PM, Eric Wilhelm <enoba...@gmail.com> wrote: > # 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
Sorry. I was imprecise. I was not saying "core" to mean "Perl core". Just what is *essential* for configure/build/test/install and what is extra to support authors. Much of the ACTION_* proliferation is just author support. Most of the feature bloat of M::B is either author support or configuration proliferation. More on this when I've written up the protocol more formally. > 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. Too much of M::B is "public" interface in my opinion and it makes the whole thing brittle. >>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. Hmm. Noted. Perhaps I'll have it only bundle if 'inc' is in @INC. Or maybe not. This is Acme, after all. I was sort of trying for a kitchen sink effect in as few lines as possible. -- David
