I can't help ya if a Build.PL file makes you break out in hives 20+ years after they were introduced but do you honestly think a beginner would have a hard time comprehending
but having no issue doing (less) withminil new My::Module cd My-Module # ...tinker minil release
module-starter --module=My::Module --email=them@cpan.org --builder=Mod +ule::Build --genlicense --ignores=git cd My-Module git init . git add .gitignore git add * perl Build.PL # ...tinker ./Build disttest ./Build dist # ... manually upload dist to PAUSE git commit -m "Here we go" git tag -m "v1.0.0" git push origin v1.0.0
Both create the same basic layout of a perl dist: the build script, lib/Fun/Module.pm, a basic test in t/, the initial changelog, etc. But Minilla also inits a git repo (opinionated, but having a repository is standard best practices regardless of language), introduces modern, organized dependency declaration by creating a cpanfile (which is understood by cpanminus), introduces the hypothetical beginner to CI by generating the Github Actions workflow I mentioned earlier, and creates a markdown README which just plain presents itself better on the web than M::S's text based one because GitHub will automatically display the markdown file on the repo's homepage. There's no messing around with the MANIFEST by hand or fiddling with how the dist gets to PAUSE every release. Without touching a config file, a brand new dev using Minilla is already off to a smooth start, in a better position to find issues before uploading to PAUSE, and none of it makes their released code any more difficult for you to install.
And when they decide to release their code, if the optional modules are installed on the author's side, Minilla makes sure of even more fidgety bits are handled automatically. It makes sure they updated their version number, tests that the minimum required version of perl is correct with Test::MinimumVersion::Fast, makes sure they won't have namespace issues on PAUSE with Test::PAUSE::Permissions, verifies they didn't forget a =back with Test::Pod, and notifies them of typos with Test::Spellunker. If all of that checks out, it updates the version number in their changelog, generates the MANIFEST based on the files stored in their repo, creates the dist, uploads it to PAUSE, creates a new commit in git, tags it with the current version number, and pushes everything to your repo. A new dev is most likely going to want to do all of those things from day one but very unlikely know which combination of plugins to add to emulate that with Module::Starter assuming they exist.
Honestly, nothing Minilla, Dist::Zilla, or the rest do to help devs out should chase you away because it's all on the author's side. And, btw, Minilla comes with support for ExtUtils::MakeMaker right out of the box if you think new devs should stick to what you're comfortable with. No plugins for them to find or install.
In reply to Re^6: How to create and name module tarball for CPAN
by SankoR
in thread How to create and name module tarball for CPAN
by Polyglot
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |