I respectfully disagree. For beginners Module::Starter is way more easy to comprehend!
My other grunch with Yet Another Authoring Tool is that you will seriously raise the bar for external contributors that do not have that tool (or any of the zillion available plug-ins) available nor have the experience with that tool nor the time to read their docs.
IMHO one should have a seriously good reason to go beyond Makefile.PL (optionally generated from Module::Starter).
I see myself as a well-seasoned perl programmer, and being confronted with releases that use Build.PL, dzil or whatever non-standard tool, will chase me away if it is not absolutely required for me to participate.
Enjoy, Have FUN! H.Merijn
| [reply]
[d/l]
[select] |
minil new My::Module
cd My-Module
# ...tinker
minil release
but having no issue doing (less) with
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. | [reply]
[d/l]
[select] |
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.
It also affects anyone that wants to contribute. There are several patches for CPAN modules that I've never offered because I am not prepared to install Dist::Zilla.
(I also still hate Build.PL - almost no distribution using it ships with any instructions on how to build using it, which I consider unforgivable.)
| [reply] |
If nothing is required on the end-user (not the module author) in order to contribute, there is absolutely no harm in using whatever system!
People are used to basic git commands now, and if I where to contribute to Foo::Bar, my routine would do:
$ git clone https://url/to/Foo-Bar Foo-Bar-git
$ cd Foo-Bar-git
$ perl Makefile.PL
$ make
$ make test
$ make install
I start cursing when there is no Makefile.PL but instead there is a Build.PL as I really, just like Hugo, hate it. But at least it does not require me to install anything else, as Module::Build is part of the core. There must be realy good reasons to choose it over ExtUtils::MakeMaker. But tastes differ.
On the other hand, systems liek dzil and others make it impossible to start working on a git checkout, as there is neither and the poor end-user is expected to install a truckload of modules and plugins that they are unlikely to ever use again.
So, if Minilla does not exactly what I describe (of course *not* choosing Module::Build), then I see no disadvantages in using it as a developer.
Enjoy, Have FUN! H.Merijn
| [reply]
[d/l]
[select] |
| [reply] |