[sf-perl] [announce] Pinto-0.026

[George Hartzell]

Bill Moseley writes:
 > 2011/12/8 Jeffrey Thalhammer <jeff at imaginative-software.com>
 > 
 > >
 > > So I invite you to kick the tires on Pinto<https://metacpan.org/release/THALJEF/Pinto-0.026> and
 > > give me your feedback.  Beware that Pinto has a lot of dependencies, and
 > > I'm still not sure what the minimum versions should be.  So I recommend
 > > brewing a fresh perl or using the -L option with cpanm(1) to install Pinto
 > > into a clean (and separate) sandbox.  Pinto is still alpha code and subject
 > > to change in incompatible ways.
 > >
 > 
 > 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?   How could developers on different machines all access a single
 > "repo" of distributions?
 > [...]

[I'm still running the previous release of Pinto, 0.24.  Some details
 may not apply to the most recent release]

[Ricardo, thought you might enjoy the Dist::Zilla tale]

We keep our PAN in subversion, with a copy of the trunk checked out in
e.g. /our/PAN/trunk.  We update and tag it from CPAN regularly with a
cron job:

  # update the mirror at /our/PAN/trunk....
  pinto-admin -r /our/PAN/trunk update \
    --force --quiet \
    --tag 'http://svnhost/pan/tags/pinto-cpan-updates/%Y%m%d.%H%M%S'

We have a pinto server running on a well known host with something
like the following command line (note that "repos" is awkwardly named,
it is *not* the path in the svn repository but rather the path to a
checked out/working-dir copy) running persistently:

  pinto-server --repos /our/PAN/trunk

We can add local distributions (either our stuff or cpan modules we
want to override) from a client machine like this:

  pinto-remote -r http://ourpan.example.com:3000 add \
    -m 'commit message goes here' ~/tmp/Acme-Widget-0.018.tar.gz

But in reality we usually push things into the pan using the
Pinto::Add Dist::Zilla plugin as part of our group's PluginBundle.

At notable timepoints "someone" will tag the trunk of the repository
and various teams will install from that tag, e.g:

  http://svnhost/pan/tags/perl-modules/2011-12-06

Given that you have your mirror of CPAN with your local stuff inserted
and broken stuff overridden, then

  cpanm -L/dir/to/install/into \
    --mirror http://svnhost/pan/tags/20111215.081019 --mirror-only
    Acme::Widget

will install Acme::Widget and all of it's dependencies (assuming
everything is probably listed in various prereqs) into
/dir/to/install/into.

The icing on the cake is that I have a Task that specifies all of the
modules that we want to install in our standard deployment, which we
generate using Dist::Zilla and its TaskWeaver, stick into the our PAN
using Dist::Zilla and the Pinto::Add plugin, and then deploy from a
datestamped tag in the svn repo like this:

env ORACLE_USERID='schema/passwd' ORACLE_DSN='dbi:Oracle:biodev1' \
  cpanm  -L /place/to/install/stuff \
         --mirror http://svnhost/pan/tags/perl-modules/2011-12-06 \
         --mirror-only \
         Task::Our::Perl::Modules::MissingPrereqs Task::Our::Perl::Modules

We actually have two Tasks, one that lists various prerequisites that
broken CPAN modules don't specify, explicitly listing them in the main
task doesn't cut it because the order in which things are installed
from a Task seems to be unspecified.  Since we let cpanm run tests as
it installs things (we expect them to pass and "fix" CPAN modules that
are failing) and since we include DBD::Oracle in our standard install
we need to set some environment variables that its tests require).
Other folk have argued for installing w/out tests.  YMMV.