If you're using Dist::Zilla, you *should* not need anything besides
META.json to install a simple module if you just set dynamic_config=0.
(This should is, of course, largely unimplemented.)
I hope a lot of Module::Built::Tiny will end up getting reused for that purpose.
Overall, it looks
::Build::Tiny
seem to fulfil the original concept of Module::Build better than that
module itself ever has.
If you're using Dist::Zilla, you *should* not need anything besides
META.json to install a simple module if you just set dynamic_config=0.
(This should is, of course, largely unimplemented
On Mon, Aug 29, 2011 at 1:50 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
I find this module intriguing.
Thank you. It grew out of Acme::Module::Build::Tiny -- which was an
exercise to determine the *minimal* API that Build.Pl/Build needed to
allow the toolchain to install a module. (Thus
# from David Golden
# on Monday 29 August 2011 08:07:
Eric raises the question why bother and I think for module authors,
at least right now, there is no burning platform to switch.
I think you misunderstand my point. Given dynamic_config support, there
is no need for a $builder_or_maker.PL
On Mon, Aug 29, 2011 at 2:25 PM, Eric Wilhelm enoba...@gmail.com wrote:
I think the most complicated part is supporting whatever
builder+installer assumptions people have encoded into their
configurations -- maybe the client could read buildrc?
For that, I'd prefer to see a new way for CPAN
things that contribute to that. I think there's a more
general everything-and-the-kitchensink issue going on in
Module::Build. In Module::Build::Tiny I'm trying to go into the
opposite direction: modularize everything that's reusable so the
central module is actually quite small and simple
be as complex as the
author would prefer. The installer can then be trivial, as indeed
it should; as well as pure Perl – as indeed, it should.
So Dist::Zilla plus the *idea* of Module::Build::Tiny seem to
fulfil the original concept of Module::Build better than that
module itself ever has
