in reply to Re: Trying to build a module for upload to CPAN
in thread Trying to build a module for upload to CPAN
I actually used Dist::Zilla for my very first module (in 2013, when Dist::Zilla was already fairly refined) and I remember there being a learning curve, but I was having just as much learning curve trying to figure out the other tools. In the end I went with Dist::Zilla because I hate having package boilerplate hanging around in my git repository, and 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.
|
Re^3: Trying to build a module for upload to CPAN
by hippo (Bishop) on Oct 29, 2021 at 09:24 UTC
|
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.
| [reply] |
|
|
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:
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";'
| [reply]
[d/l]
[select] |
|
|
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.
| [reply]
[d/l] |