[sf-perl] Tools and work flows for developing collections of distributions

David Christensen dpchrist at holgerdanske.com
Sat Dec 8 10:11:52 PST 2018

 > David Christensen <dpchrist at holgerdanske.com> wrote:
 >> makemaker:
 >> I use h2xs, ExtUtils::MakeMaker, and make(1) on Unix-like platforms
 >> for developing Perl modules and collecting them together into
 >> distributions.
 >> I now have several distributions and would like to develop and test
 >> them together (preferably, without installation).
 >> How do people on this list develop and test multiple dependent Perl
 >> module distributions?
 >> TIA,
 >> David
 >> p.s. I have posted similar threads to the module-authors and makemaker
 >> lists, but haven't found a satisfactory solution:
 >> https://www.nntp.perl.org/group/perl.makemaker/2018/12/msg3414.html

On 12/7/18 10:37 PM, Brad Lhotsky wrote:
> I've been using Dist::Zilla for my distributions and it makes things 
> *so* much
> nicer.
> Here's David Golden's explanation why:
>     https://xdg.me/blog/why-im-using-distzilla/

Thank you for replying. :-)

I evaluated Dist::Zilla several years ago.  At the time, the complexity 
didn't seem to be worth the effort.  Perhaps, now it is.

> I still write out my dist.ini's, I should convert this workflow into a 
> bundle,
> but I'm too lazy.  Here's a sample:
>     https://github.com/reyjrar/es-utils/blob/master/dist.ini
> If you were to clone that, you could:
>     $ cpanm Dist::Zilla
>     $ dzil authordeps --missing |cpanm
>     $ dzil listdeps --missing |cpanm
> Then you could develop, and then `dzil test` to run the test suite, `dzil
> xtest` would run the author tests.
> Dist::Zilla + Pod::Weaver and it's taking care of:
>     * Pointing META resources at GitHub
>     * Automatically compiling and inserting into POD the Contributors
>     * Dependencies
>     * Managing the release versioning via git tags so all I need to do to
>       release is `dzil release`
>     * Generating a Changelog from the repository history
>     * Gives me shorthand for POD with things like =method / =attr and
>       collects/formats the POD
> And in this instance, it's pulling some of my POD out and injecting it into
> the repository so people on GitHub can view some of the documentation:
>     https://github.com/reyjrar/es-utils/blob/master/CopyIndexes.mkdn
>     https://github.com/reyjrar/es-utils/blob/master/Maintenance.mkdn
>     https://github.com/reyjrar/es-utils/blob/master/Searching.mkdn
> All of that Markdown comes from the POD in the distribution and is
> automatically updated anytime I build/install/release.

Is es-utils available on CPAN?

> If Dist::Zilla is "too big," you can check out 
> https://metacpan.org/pod/Minilla

The POD states:

     "Minilla has a bold assumption and convention like the followings..."

     "Your module is maintained with Git and git ls-files matches with 
what you will release"

I would prefer a workflow model whereby the version control system (VCS) 
is orthogonal -- e.g. I can use any VCS, including several at the same time.

If the concept of a tool is VCS integration, I would prefer that the 
tool do so through VCS plug-in's (and support CVS).

> That's distributions, but if you wanna a mock your own CPAN for your
> distributions, there's Pinto.
>     https://perlmaven.com/pinto-tutorial

I've tried at least one local, private CPAN repository work-around.  The 
fact that yet another has been created tells me that the root cause 
problem(s) have not been completely identified nor addressed.

> Of course, there's a dzil plugin for indexing to your pinto install:
>     https://metacpan.org/pod/Dist::Zilla::Plugin::Pinto::Add
> Now, for testing distributions separately, I've been using/testing Carton:
>     https://metacpan.org/pod/Carton

A work-around for another fundamental problem (dependency hell).

> There's a write-up about using these tools together for micro-services
> deployment:
> https://engineering.semantics3.com/a-perl-toolchain-for-building-micro-services-at-scale-8851626a4b1b 

It's interesting to read about a commercial Perl shop work flow.  But, 
there are at least two deal breakers for me:

1.  Commercial services from GitHub.

2.  Where is the code/ what is the license for "sem3 build"?


More information about the SanFrancisco-pm mailing list