<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 7, 2011, at 8:57 PM, Bill Moseley wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Can anyone offer comments on how this is done in your organization?</span></blockquote></div><br><div>At least one organization that I know of uses Pinto to keep snapshots of CPAN in Subversion.  They have a text file that just lists the packages they want to have installed in their site_perl.  Then they point cpanm at the Pinto repository (or directly at the snapshots in Subversion) and feed the package list to cpanm.  So it looks something like this:</div><div><br></div><div>$> cpanm --mirror /path/to/pinto/repos --mirror-only < wanted_packages.txt</div><div><br></div><div>And voila!  They can stamp out a new perl environment with precisely the right dependencies each and every time.  If someone just wants to make a sandbox environment, they can just use the -L=some/directory option to create the environment in some/directory.  Or they could brew a fresh perl and install there (after bootstrapping cpanm).  The also publish their in-house distributions to the same Pinto repository, so the environment includes both third-party CPAN packages and their own stuff too.  </div><div><br></div><div>You can also store the "pre-built" modules in Subversion as Jon suggested (I've done that too).  But the advantage of using Pinto is that it stores the actual distributions.  So you can easily rebuild your dependency stack on a new architecture or with a different perl, and you get a full smoke test each time.  In addition, Pinto provides you with tools for upgrading your stack in a controlled manner, so you can handle new packages from the CPAN that aren't compatible with your code.  And if you use the built-in VCS capabilities of Pinto, you can rollback when things go wrong.</div><div><br></div><div>I do like Paul's suggestion of keeping machine images, especially for large systems that require more than just a bunch of Perl modules.  But you can still use Pinto to build the Perly bits of those images in a controlled, reproducible fashion.  In fact, you could even use the OS packaging system (e.g. debian or rpm) on top of Pinto, to combine Perl modules, web servers, databases, and whatever infrastructure you need.  </div><div><br></div><div>Personally, I strive to make every system reproducible and isolated.  I want to be able to stamp out the whole wad at any time with the push of a button.  And I want to be able to have as many wads on the machine as I want.  For the Perl parts, Pinto gives you the ability to use the CPAN toolchain to assemble modules (including your own) in a reliable and predictable way.</div><div><br></div><div>-Jeff</div><div><br></div></body></html>