[sf-perl] Moose, mouse, cpanm long story

yary not.com at gmail.com
Fri Apr 20 05:45:06 PDT 2012


Around the time the various Moose threads started I was faced with a
medium-ish sized Perl project at work. Most of the perl projects
before were small or started small and grew to medium, and weren't
object-oriented in any way. This project would benefit from OO
structure, so I dove in and used Moose.

The time saved from writing and re-writing bits of setup and checking
code made up the learning curve within the first week. Its constraint
checking found some errors quickly that would have had me sprinkling
printfs or using the debugger otherwise. It's made it easy to focus on
what my code needs to do and worry less about the mechanics of fitting
the pieces together.

That said, I fibbed a bit. I'm using Mouse, not Moose. This is a
command-line tool where startup time matters, also it needs to be
installed on machines behind strict firewalls where we don't have many
privileges. In fact at the time the project started, I couldn't even
be sure what version of perl was on the target host or if it had any
compiler tools available. Using any non-core modules meant downloading
them somewhere else and scp'ing them over, only pure-perl acceptable.

Mouse has no dependencies and has a pure-perl version, and it worked
perfectly from start to finish during development. I was wary of their
warning "if you see strange errors, use Moose" and kept watch for each
new bit of Mouse I used, but it solidly did what the docs said it
would. Perhaps that warning was for users of the various Mo[ou]seX
modules on top of Mouse.

That said, I fibbed a bit. The dev machine has the cpan client
installed and the firewall does let cpan load modules via ftp. By
using local::lib and fatpacker (scp'd over) I was able to have cpan
build modules in the home directory, and then I could put the
essential bits into the project's "lib". I did that for Mouse.

What I didn't realize until I deployed my project to the hitherto
mystery production box was that cpan had built Mouse with the
compiled-C XS backend on the dev box. And the production machine has
perl 5.8.8 but the dev has perl 5.8.7 so that compiled back-end won't
work in both places. "No problem," I think, "I'll just have Mouse use
its pure-perl backend". I remove the deployed Mouse files from the lib
tree (including the object file hiding in "auto"), build Mouse with
Pure::Perl from source- just a couple commands inside the unzipped
source dir- put it in place, and test my app.

Oops, there are some strange errors. Or rather non-errors, the code
runs but stops without producing any output in one simple test. Is
this what that warning was about? Perhaps the Mouse developers worked
out all the kinks in the C/XS version and didn't port those fixes back
into the Pure-Perl version.

"No problem," I think, "cpan will rebuild it for me on the production
box too"- only the compiler chain is also different on the prod box,
and the it can't compile Mouse's C code. I'm fine with C, learned that
before Perl, but I don't have time to dive into it. I don't think I
mentioned that deploying to the prod box was happening the morning of
a demo that was that afternoon, and I also had received a directory
full of sample files that morning that had to be used in this demo.

Now, I had heard of cpanm ("cpan-minus") many times, and was a cpanm
skeptic. I have always had success installing modules with the cpan or
cpanp ("cpan-plus") clients. But then, that was mostly on my own
machines, and here I was in a situation where I could not install the
Mouse I needed, not from pure source nor from cpan, and had no time to
fiddle with settings. I scp'd the standalone "cpanm" perl program,
pointed it at the Mouse working directory cpan had started- and cpanm
built it, compiling the C backend, on the first try. So now I'm a
convert... though I will save it for the sticky cases.

I fibbed a bit. That error from the pure-perl Mouse? I'm not sure it
was Mouse's fault after all. This work project talks to a SQL
command-line tool, which is also different versions on the dev and
production machines. The versions differ subtly in both the way they
get the password and the way they report errors, so I had to figure
those out, and make my code do something both versions accepted.

phew. That's that for now... I do have some more thoughts on Moose,
and some questions on how to best structure a part of my code, maybe a
little later.

-y
ps. Dev & deployment has been on locked-down Solaris boxes. Eventually
these will also run on Windows boxes using ActiveState perl, with far
more "core" modules pre-installed, and I've been able to update
existing modules/add new ones with "ppm"- so cpan[m] is not an issue
there.

pps. Sorry to join in the Moose-ish conversations late. It seems there no
 $time !~ /work|home/


More information about the SanFrancisco-pm mailing list