in reply to Re^3: Making the CPAN/GitHub updating process painless
in thread Making the CPAN/GitHub updating process painless

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.

Replies are listed 'Best First'.
Re^5: Making the CPAN/GitHub updating process painless
by Corion (Patriarch) on Dec 17, 2017 at 13:37 UTC

    One of the downsides to Dist::Zilla is that it makes it almost impossible to contribute for people without Dist::Zilla installed.

    At least the way some people use it to write non-pod documentation and build the test suite, I found it impossible to submit a tested patch agaist the repository and still run the test suite, as both needed Dist::Zilla installed.

    Dist::Zilla at least at one time failed its test suite on Windows.

      I can't see how that would be the case. At least I've never encountered it. I agree that some implementations can make some things difficult or impossible: you can't read the Pod in a module using perldoc if dzil hasn't built the distro, for example (I don't use Pod::Weaver's "magical" features for that reason). However, I have never encountered a situation where writing or running tests was affected. The tests should be able to use the library irrespective of the condition of Pod or the inclusion of dzil-specific directives. While you can run tests with dzil test you can equally just use prove.

      I am not sure whether Dist::Zilla runs or passes its tests on Windows. I would say it's quite rare in general for a CPAN author to develop on Windows, and the fact of the matter is that Dist::Zilla has become the de facto standard for releasing to CPAN. This is simply because once you spend the time to learn it, it saves you hours of time and aggravation when updating a distribution. I urge anyone who contributes original or patched content to CPAN to bite the bullet and spend half a day getting up to speed. You'll be glad you did!


      The way forward always starts with a minimal test.

        I've experienced this problem Corion is talking about, a released version of one of the many plugins was failing, and borked the installation process. Had to dig reasonably deep then install a development version of the plugin from github to get d::z to even install.

        Even if it is rare for a Perl developer to develop under Windows, that statistic doesn't help me. I develop 90% of my CPAN modules on Windows, so Dist::Zilla not working or not intending to support Windows directly rules it out for me.

        I am not sure whether Dist::Zilla runs or passes its tests on Windows. I would say it's quite rare in general for a CPAN author to develop on Windows, and the fact of the matter is that Dist::Zilla has become the de facto standard for releasing to CPAN.

        10% adoption sandard? Heh. Its popular so it has to be good :p Doesnt even have to be backwards compatible

Re^5: Making the CPAN/GitHub updating process painless
by Your Mother (Archbishop) on Dec 18, 2017 at 13:21 UTC

    My advice was: there is more than one way to do it and this might suit you, but if you think this one is not a good match for you, it's not a surprise because it wasn't made for beginners and you are not alone and don't have to feel obligated to force it because one data point said it was necessary.

    I tried using it for awhile and it got in the way and sucked up time trying to merely replicate a multi-command, one-line alias I've been using to build and test distributions for 15 years. Maybe that's a failing on my part and I'd be happier if I'd sunk the time but I do releases rarely and it's a trivial one command, one upload, one minute process for me already. It would have cost me many hours to save maybe most of one.

    you're unlikely to be able to cross all the Ts and dot all the Is

    The CPAN survived a long time and grew to thousands of packages without Dist::Zilla and I doubt it's even used by a third of authors today so the comment amounts to FUD.

    As to 800lb gorillas, I think they all must be weighed, har-har, carefully. Moo is not really one. DBIx::Class has no analog other than Rose::DB and it is an investment in making ongoing workflow easy which is exactly the use pattern I said Dist::Zilla made sense; I adore and recommend DBIC often but I have never once said, this is the only way to do it, and I acknowledge its shortcomings to certain kinds of power users. I would never recommend Moose at this point; it does too much that most users never care about or want to see and there are plenty of much lighter alternatives that work with uncoupled sidecars like Type::Tiny. DateTime is fantastic in its scope and attention to detail; its size and architecture makes it the worst choice in situations where a million or so dates at a time need to be processed so it's not a gimme any more than the others. This reminds me of apache as well, which I would also never recommend today despite it being the unambiguous feature king. Eschewing apache did not lead to dumbed down webservers but instead to the lean, lunch annihilating nginx which is now powering a third of the web and is the only webserver growing in usage.

      you're unlikely to be able to cross all the Ts and dot all the Is
      The CPAN survived a long time and grew to thousands of packages without Dist::Zilla and I doubt it's even used by a third of authors today so the comment amounts to FUD.

      Wow, speaking of FUD, that's an impressive amount of mischaracterizations of what I said that you packed in there. Here's my original statement:

      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.
      • Does not mention Dist::Zilla, but rather releasing by hand.
      • Does not mention CPAN, but rather meta::cpan and its indexing/linking features.
      • Twisting my words to make it seem that what I was saying was that CPAN's success depends on Dist::Zilla is total argumentative BS.


      The way forward always starts with a minimal test.

        So untwist the words. What is likely to be unlinked or missing from the indices if one doesn't use Dist::Zilla?

Re^5: Making the CPAN/GitHub updating process painless
by nysus (Parson) on Dec 18, 2017 at 22:25 UTC
    This means there is a learning curve, and I doubt that the OP in this thread could accomplish setting it up for himself.

    You only belie your own insecurities with such snark. And to the contrary, I was able to try out all the different versioning systems without much trouble at all.

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