Ah, OK, I first saw this package referenced by Dancer2 project. Was wondering WTF it was. I'll go this route. Thanks. There is an interactive tutorial here: tutorial.

Dist::Zilla is an 800lb gorilla primarily designed for busy CPAN authors of multiple packages. Like Corion, I don't use it. I set it up back in the day but it has, in my estimation, a lopsided cost to benefit ratio for the casual or infrequent author. You'll have to decide if it suits your use case and preferred workflow.

There is more than one way to do it. You can release by hand if you want. I don't recommend that because you're unlikely to be able to cross all the Ts and dot all the Is required by meta::cpan in order to properly index your module.

Dist::Zilla automates releasing to CPAN, and is highly configurable. There is more than one way to do it; for example there are half a dozen ways to manage version numbering. This means there is a learning curve, and I doubt that the OP in this thread could accomplish setting it up for himself.

However, as I mentioned in my reply, you can look at the config files for any existing distro and steal what others have used. Many authors publish a bundle of their configs on CPAN, and while that's rather vainglorious in many cases, you can download and study those. My own dist.ini is heavily based on David Golden's author bundle. Also the support group on #distzilla is one of the most active and helpful Perl IRC channels.

Just the fact that a tool is powerful and complex is no reason to discourage its use for the purpose it was designed. I am far from a prolific CPAN author, but I have a few current modules, and much more frequently I contribute to other distros. If I wasn't familiar with dzil I wouldn't be able to collaborate like that.

Moose/Moo, DBIx::Class, Chart::Clicker and even DateTime are other examples of 800-lb gorillas: I don't agree that Perl programmers should be advised against using them because they are complicated. That just leads to dumbing down of code and distros on the CPAN that have no value.



The way forward always starts with a minimal test.

You'll have to decide if it suits your use case and preferred workflow.

if you can get it to work in any at all :)

OK, got it working. Is it a good idea to release the Manifest, yaml and other such files for cpan to github? I see it done all the time but seems to just get in the way.

The rule is simple: what can't be generated belongs to version control. What can be generated doesn't belong there.

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

OK, had to mull that over. So answer is "no, those files should not go there." Sounds like a good rule to follow.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate Priest";
$nysus = $PM . ' ' . $MCF;
Click here if you love Perl Monks