[sf-perl] Go Pinto [Was: Real perl]

[Jeff Bragg]

Doing things without a lot of dependencies isn't necessarily "doing things
the hard way".  I lean heavily on the core packages, and use CPAN modules
for virtually anything non-trivial, as I don't have time for a lot of
unnecessary wheel-inventing.  However, as I said, I don't always have the
luxury of assuming the resources I'll have available, outside of Perl
itself and some indispensible BASH/Linux utilities.  Some machines I have
control over, and can install what I please; others I have much more
sharply limited control over, and cannot, for example, even assume that the
CPAN kit is complete enough to build everything -- without a few specific
packages or external tools, e.g. the YAML library, make, I've seen CPAN
fail spectacularly to install what I needed.

And again I'll say, Moose, nice as it is, is overkill for much of what I
write; most of my scripts will already be most of the way finished running,
as currently written, by the time Moose loads.

I'll keep Pinto in mind because it may be useful for situations in which I
have sufficient control to use it.

Honestly, I was generally praising Moose as a good thing, but a little
heavy for some things, and just stating a fact about the situation I have
to work with; I'm not sure why you chose me to make an example of.

I feel like the Perl community is becoming pretty damned opinionated; in my
view TMTOWTDI does not just mean that there's a "right" way and a "wrong"
way (that kind of binary thinking is for other language communities).

On Tue, Apr 10, 2012 at 9:59 PM, Jeffrey Thalhammer <
jeff at imaginative-software.com> wrote:

>
> On Apr 10, 2012, at 4:19 PM, Jeff Bragg wrote:
>
> I've used Moose, and found it to be very nice, especially in comparison to
> old-school Perl OO.  However, it usually seems like overkill for my
> purposes (and perhaps a violation of the KISS principle).  I'm sure it has
> a lot to do with context; I'm generally doing systemsy, back-end stuff, and
> prefer to minimize my dependencies and assumptions about deployment
> environment.
>
>
> Then please allow me to use this opportunity to make a shameless plug for
> Pinto <https://metacpan.org/module/Pinto>.
>
> IMHO, dependency avoidance is a weak excuse for doing things the hard way
> (and usually the wrong way).  But installing stuff from the public CPAN is
> a lottery because you never know exactly which versions you are going to
> get.  And if you want to lock down those versions with a private CPAN, it
> is a fair bit of work to manage.  So dependency-phobia lives on.
>
> Pinto <https://metacpan.org/module/Pinto> aims to fix all that.  Pinto
> makes it super easy to construct a custom repository of CPAN distributions
> (including your own private ones) and organically evolve your dependencies
> over time.  So now all that "systemsy back-end stuff" can leverage anything
> and everything on CPAN, and you've got a solid, reproducible mechanism for
> building, testing, and deploying it.
>
> -Jeff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20120411/37adb01f/attachment-0001.html>