[sf-perl] [announce] Pinto-0.026

[Jeffrey Thalhammer]

On Dec 15, 2011, at 2:37 AM, Bill Moseley wrote:

> I'm trying to understand the big picture.  Any primer or "getting started" docs to help the impatient?  Or maybe just a walk-through of typical workflow?

Yes, that is on my TODO list.  For now, let me give you a quick demonstration (below)

> My goal at this point is to have a private CPAN-style repo available on our LAN where we can add our in-house modules and run "cpan Our::Module" and have it automatically install from our local repo (or from CPAN, if it lives there).

That is precisely what Pinto is designed to do.  Here's what it would look like using a repository on a shared drive:

# Create a Pinto repository on some shared storage
pinto-admin -r /some/shared/directory create

# Put some of our private distributions in the Pinto repository
pinto-admin -r /some/shared/directory add My-Stuff-1.2.tar.gz  More-My-Stuff-0.03.tar.gz

# Install our code from the Pinto repository, falling back to the CPAN for any missing dependencies
cpanm --mirror file:///some/shared/directory My::Stuff  More::My::Stuff

If you don't like the idea of shared storage, then you can use pinto-server and pinto-remote (sold separately) to communicate over HTTP:

# Create a Pinto repository on some networked server.
ssh myserver
pinto-admin -r some/directory create
pinto-server -d -r some/directory
exit

# From another machine, put a private distribution into the remote Pinto repository
pinto-remote -r myserver add My-Stuff-1.2.targ.z

# Install our code from the remote Pinto repository, falling back to the CPAN for dependencies
cpanm --mirror http://myserver:3000 My::Stuff


These are probably the simplest ways to use Pinto.  But you can do some fairly sophisticated things with too.  For example, you can make snapshots of the CPAN, so you get the same set of distributions every time you build.  And then you can systematically evolve those snapshots by upgrading some modules while holding other modules constant.  Also, you can connect multiple Pinto repositories together and create a network for sharing modules across teams or departments.  And Dist::Zilla::Chef is an experimental set of DZ plugins that create a workflow for using Pinto in the development process (similar to Miyagawa's Carton).


> I don't think we want to check out an "installed" Perl lib (say a copy of a local::lib library) due to different architectures.  We too often get developers blocked due to some common module dependency issue using shared libs -- I think developers with their own local::lib or even perlbrew is the easiest way for everyone to get along on the same machine.

local::lib and perlbrew definitely go a long way toward making sandboxes.  But installing into them from the CPAN is a risky game.  The CPAN is not stable and modules are constantly
coming and going, so you may never be able to build the same sandbox twice.  Pinto can solve this problem, giving you predictable, reproducible sandboxes.

> Frankly, I don't think it's that hard to svn checkout the module and install it manually using local::lib, but some our of code has so many in-house dependencies that it's somewhat of a pain to do that if some time has passed since last working on the code.  Plus, svn may have the module in an unstable state and not "release" ready.   Just running Makefile.PL && make on one of our apps to bringi in all the in-house dependencies would make it much less painful.   And make preparing RPMs for a release simpler, too.

Yup -- that is the goal (in essence).

-Jeff


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20111215/a76b4a8f/attachment.html>