What do I use to release a module to CPAN for the first time?

Several months ago I read a tutorial on module creation. It got me thinking about releasing some of my modules. I got to work getting my code organized. At the time I had all of my work in the directory for my site. So I moved my general purpose modules to their own directory and then started reading more about what is needed to get a module published on CPAN.

I first installed Module::Starter. It seemed like a good place to start, but then Dist::Zilla was suggested, so I installed it. Most recently Minilla suggested, and now it is installed. The problem is, I do not know which one to use. Do I use any of those at all, or is there yet another packaging module (with executable) out there?

Module::Starter (module-starter) appears to be for those starting with well thought out plans for what they want to write. I have been told Dist::Zilla (dzil) is not for a first time releaser. Minilla appears to be for those who have a complete package written and just need to get it compressed to send to CPAN.

I have also read Release::Checklist.

I know after the code, documentation, and tests are written; the rest should take maybe half an hour or less. I have lost all confidence I had several months ago when I thought it would be easy. I am drowning in an ocean of documentation that most might find to be only a wading pool. I am reaching out and grasping at whatever scrap I can find that might match my specific circumstances, but I keep getting bogged down. I am fairly sure releasing modules to CPAN should not cause tearful emotional breakdowns on a semi-regular basis, especially when it is just one module with less than 30 lines of code to it.

My circumstance is I have around 60 free floating .pm files I am thinking about publishing to CPAN. All have plain old documentation in various states of completion. All have at least their first tests written. (Only 2 have more than the use_ok test in a BEGIN block.)

The module I want to release first is Fancy::Open. It has a separate .pod file and one test file.

Where do I go from here? I am willing to do this all "by-hand" if need be since this is my very first package and release.

Apologies if this is not well written. I am so confused, but I do not want to give up like I have on other aspects of Perl.

I have sought wisdom on PerlMonks.

Where do you like bugs reported?

In my last post, a meta issue for modules: bug tracking, I had noticed a problem with the bug tracking link for a module and discussed that problem. In the comments, one person said he preferred rt.cpan.org. I began thinking about where to have bugs tracked for my modules. Since I have not published one yet, this is something I would like to know. I would like to know the good and bad and ugly of the various systems to make a more educated choice on issue tracking before my first release.

Are there specific issues with GitHub's, GitLab's, or other issue tracking systems making rt.cpan.org the more attractive choice?

On a side note, I prefer reporting issues on sites like GitHub and GitLab since my reply email is hidden and does not get spammed, or at least not yet. However, my cpan.org email address gets a lot of spam, so much spam I had to make a rule to send all email I receive through that address to junk mail. So, should I receive a reply to an issue I opened on rt.cpan, I may miss it since it ends up in my junk mail, which I do not check that often.

Where do you like bugs reported and why?

A meta issue for modules: bug tracking

I was reading a module on meta::cpan when I spied a small issue. I went up to the Issues link, clicked, and was sent to rt.cpan. I know that many module authors now have their modules on sites like GitHub, GitLab, or Bitbucket. Before I posted the issue on rt.cpan, I checked the author's profile for a linked account to one of the other sites. I found the module on GitHub and read the CONTRIBUTING.md to find the author does want issues reported there and not rt.cpan. I did not report my original issue, I reported the link issue instead as it seemed more important.

Today is not the first time I noticed this issue with a module's bug tracking.

Before continuing, I have not released a module to CPAN and am still learning all that goes into releasing one. Please be gentle if I am wrong or stating an obvious well known fact.

I read one of the META.json resources called bugtracker can be set to a URL on the preferred platform. So, have CPAN authors checked their META.json files to make sure issues are being linked to the right place by meta::cpan?

For those modules written before the use of other sites for bug tracking, will issues on rt.cpan get ported over to the new bug tracking location? Should there be a link to rt.cpan somewhere in the documentation for older modules whose issues have been moved away from it? Issues closed as a wontfix, for example, on rt.cpan could rear their heads on the new bug tracking platform possibly making more work for the modules' maintainers if not noted somewhere. There could be duplicate issues in both places too.

One known problem with porting issues from rt.cpan to another platform could be problematic because of the use of different user names by issue reporters and maybe even module maintainers. For issues I have raised on rt.cpan, my user name is "ALEENA"; for issues on GitHub, my user name is "LadyAleena". However, both of those identities are connected through my meta::cpan account, so that could be used to resolve user name mismatches.

To all those who have modules on meta::cpan, does it link your bug tracking to the correct location?

Why I don't try the Perl Weekly Challenges

A little over a month ago I learned about the Perl Weekly Challenges. The site states the challenges are for any skill level. So, I went and took a look. After looking at the first challenge that week, I realized “any skill level” did not mean my skill level.

My skill level is pretty basic.

I can …

  • open, read, and close text files and do simple manipulation of the data.
  • add, subtract, multiply, and divide when it comes to math.
  • tack on words or phrases to the beginnings or ends of strings okay with loops.
  • write some basic regexen.
  • even roll things randomly.
  • do most of the above conditionally.

… that is about it.

I read the challenges and my mind is totally blank on where to start after…

use strict;
use warnings;

I wish I could grasp the concepts in the Perl Weekly Challenges, especially the math. I have not taken a math class in over 30 years, and what math I remember is, as I said, pretty basic.

Oh, and one needs to be more than a little familiar with Git and GitHub to contribute, which I am not.