# from Aristotle Pagaltzis
# on Sunday 28 August 2011 22:50:
In my understanding, the complexity of Module::Build piled up
because the same tool tries to cover both installation and
authoring use cases.
I've often had that thought, though I would say that M::B definitely
suffers from being a
On Sun, Aug 28, 2011 at 2:38 PM, Arthur Corliss
corl...@digitalmages.com wrote:
Google switching to SSL by default is as pointless as metacpan. In
the former case it's the protection of delivery to/from an entity that
not only doesn't have your best interest at heart, but has a business
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
On Mon, 29 Aug 2011, David Nicol wrote:
I'll take this bait, swallow it, and hopefully bite off the line:
Yes, Google is going to use query data for its gain. But, Google's
business model
also involves *aggregation* and *respecting individual privacy*.
The SSL to Google Search is supposed to
On Mon, Aug 29, 2011 at 7:50 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
I find this module intriguing.
I'm happy to hear that :-)
In my understanding, the complexity of Module::Build piled up
because the same tool tries to cover both installation and
authoring use cases.
There are many
