in reply to Re^5: How to create and name module tarball for CPAN
in thread How to create and name module tarball for CPAN

Okay.

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 

minil new My::Module
cd My-Module
# ...tinker
minil release

[download]
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

[download]

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.

Replies are listed 'Best First'.
Re^7: How to create and name module tarball for CPAN
by hv (Prior) on Nov 28, 2023 at 17:14 UTC

    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]
      Dist::Zilla isn't the beast I brought up first but Minilla, on the other hand, generates a plain ol' Makefile.PL when minting a new dist like so: minil new --profile=ExtUtilsMakeMaker My::Module. No need to install Minilla to contribute to a project started or managed with Minilla. It just makes the rough bits smoother for people who might have questions like op.
[reply]
[d/l]
[select]
Re^7: How to create and name module tarball for CPAN
by Tux (Canon) on Nov 28, 2023 at 18:52 UTC

    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

    [download]

    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]
      Yeah, what you're describing is exactly how Minilla works.

      minil new -p ExtUtilsMakeMaker Acme::Random::Perlmonks::Example

      ...results in what you'd find here: https://github.com/sanko/Acme-Random-Perlmonks-Example. The repo can be installed by cloning it and running the Makefile.PL as you would or with cpanminus like this:

      cpanm https://github.com/sanko/Acme-Random-Perlmonks-Example.git

      All without requiring end users or co-devs to install or even think about Minilla. It generates complete, ready to go boilerplate and gets out of the way.

      After a full decade of development, it really does deserve broader use but it's largely ignored or simply unknown by the people in the best positions to steer new eyes towards it which is why I can't mention it often enough. It's a great tool.

[reply]
[d/l]
[select]
Re^7: How to create and name module tarball for CPAN
by Polyglot (Chaplain) on Nov 29, 2023 at 14:22 UTC
    Thank you for helping me understand the reasons for steering clear of minilla. I'm not too interested in dealing with git, have no account there, and would rather keep it that way--so if minilla automatically involves git, it's not what I wish to use. That said, you have spoken eloquently for it, and if I had a git presence, you would likely have sold me on minilla.

    I would tend to side with those avoiding Build.PL as well. I'd rather have something more intuitive to install.

    Blessings,

    ~Polyglot~

[reply]
      Just as you can use Perl locally without having a user account on Perlmonks, you can use git locally without an account over at github, gitlab, bitbucket or the like.

      You can read more about git over at https://git-scm.com/. However, my favourite git "tutorial" is Git Magic. Of course, you can read that also without using git ;-)

      From the Preface (which could also be said about Perl):
      As Arthur C. Clarke observed, any sufficiently advanced technology is indistinguishable from magic. This is a great way to approach Git: newbies can ignore its inner workings and view Git as a gizmo that can amaze friends and infuriate enemies with its wondrous abilities.
      BTW congratulations to your 333rd post!
[reply]
        Half way to 666. I'm sure they'll love that.
[reply]
      You're free to steer clear of basic, automated assistance but, judging by this thread, you probably shouldn't.
[reply]

In Section Seekers of Perl Wisdom