You, sir, are a trooper and I take my hat off to you.

I, along with some other denizens of these halls, participated in the Pull Request Challenge a few years back and when it so happened that the module I was assigned required Dist::Zilla my heart would sink. Such an overblown, unnecessary framework - complex and heavy in equal measure - which for a single run-and-release gives back very little. I can fully understand why folks like RJBS and perlancar would use it but it is not for me.

because I can't ever remember to do all the manual steps during a release like updating all the version numbers in each module and updating the Manifest and tagging in git, etc.

I wrote a script which does that for me. It is entirely unnecessary for anyone else to have that script or know that it exists. This means that they can collaborate with me on my modules in GitLab (or elsewhere) without having to use either my script or Dist::Zilla or anything else. It is no barrier to participation.

---

🦛

For me, updating the manifest is pretty much standard procedure whenever i add or remove files from one of my projects. As for updating version numbers and stuff, i also have scripts for that.

setversion.pl:


Read more... (2 kB)

It's probably not the most efficient of scripts, but it does the job for me in a lot of open source and closed source projects. This one is taken directly from my Net::Clacks repository. The script is in the "devscripts" directory, which also holds such gems as "fixpragmas.pl" that allows me to change the standard pragmas for all *.pm files in a project all in one go.

perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'

Thanks, but I don't think it was really anything to congratulate, because I was literally starting from a blank slate looking for the combination of tool and documentation that would make my life easiest. And its entirely possible that I took the harder path, but from the available information at the time it seemed like the right choice, and having learned the tool I think it has saved me effort over the years. I'm just contributing my experience to the discussion where the goal is probably to determine the path with the lowest cognitive overhead for a new module author.

I wrote a script which does that for me

and when I started I wouldn't have known what a script like that would need to do. It takes time to learn the structure of a package and read about all the config options for MakeMaker to find out which parts are already solved and which need solved with additional scripting.

I do agree that its unfortunate that dzil is based on such a large dependency tree. On the upside, all you need is cpanm Dist::Zilla; dzil authordeps | cpanm to get started, and you can use perlbrew to make a self-contained perl to use for the pull request challenge, and then delete it all when you're done.

Thanks for pointing out the link to the guide -- I originally skipped it, as one of the references said, Oh that uses h2xs, that's ancient. After looking at the guide a little more closely this morning, it looks like it has everything I need to more or less do the needful. I appreciate your feedback, and I'll try this out tonight after work. :)

I still use h2xs for pure Perl modules - think I probably need to update that. Is this still state of the art for XS starters?

I also noted in Minilla, assumes among other things:

> Your modules are written in Pure Perl and are located in lib/.

Thanks for your response! Replies to this node suggest that h2xs is outdated. As I point out in my post, I tried Minilla, and had some issues with it.

I spent a few hours Friday night figuring out what was wrong, and determined that my MANIFEST file was incomplete. I also discovered that the POD Coverage tool fails to find POD in the named module under the lib directory -- once I'd added use lib './lib' to the test, it just worked. I've learned a lot.

I've also figured out that my man page for the module is deficient -- I include a command line tool with the module, but I don't mention it at all in the POD, so I have to fix that omission. I've written a script to automate building a release (of course) and I copy files from the module directory into the CPAN directory if they're absent, but I don't do a cp -u $src $dest as I should. (Tangent -- I wrote a REXX script to do that on OS/2 in the early 90's. It was super useful.)

The journey continues.

Alex / talexb / Toronto

Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.