Almost all the members of the App namespace have lower case names. I don't fully understand this aspect of CPAN, but if you look at things like App::cpanminus or App::pherkin, you will see where I got the idea. I think it is so that the command can be run from the command line in the traditional *u*x way, with the name being all lower case. Were it a pure module, I would agree with your case convention.

As far as choosing the modulino form is concerned, I want something runnable from the command line but at the same time testable. The modulino is the best fit I know for this combination.

Right now, it's purely on my own system as I am trying to work out the hierarchy needed for CPAN. I have done it before, but not for a modulino.

Regards,

John Davies

As far as choosing the modulino form is concerned, I want something runnable from the command line but at the same time testable. The modulino is the best fit I know for this combination.

Notwithstanding the enormous respect I hold for both you and brian_d_foy, I just can't bring myself to embrace modulinos, they just feel too sneaky/clever for my tastes ("scripts should use modules, not pretend to be modules").

Plus I've always enjoyed developing my modules with TDD, keeping the commands really small, with all heavy lifting done by modules (the approach taken by Perl-Tidy and Perl-Critic, for example).

Anyways, thanks to your modulino questions, I now have yet another list: modulino references :)

"Almost all the members of the App namespace have lower case names."

I just typed "App::" into https://metacpan.org/. The list presented did have a lot that matched /^App::[a-z]/ but the majority matched /^App::[A-Z]/. I acknowledge that the list was incomplete. I don't see /^App::[a-z]/ as being a convention or even preferred usage.

"... App::cpanminus ... I think it is so that the command can be run from the command line ..."

I haven't spent any time investigating this. I know that App::cpanminus has the command cpanm, not cpanminus. I also know that the first module presented in the list I referred to above, App::Ack, has the command ack, not Ack.

"I want something runnable from the command line but at the same time testable."

As I said originally, "Without any code, it's not really possible to make many comments about this."; however, as it stands, I don't know what problem you're facing with a normal (non-modulino) module. Perhaps you could expand on this.

In closing, both ++NERDVANA^#11147204 and ++eyepopslikeamosquito^#11147206 make good comments about lib/ and bin/. Also, NERDVANA's remarks regarding naming are valid.

— Ken

I have pushed a release candidate to github at https://github.com/DrJHD/ipchange. It's not final. I want to improve the POD to clarify that it is looking at public facing IP addresses. I am also thinking about a better name (thanks, NERDVANA, for the helpful advice). I have got Dist::Zilla to produce a CPAN-friendly tar.gz. It has been suggested that I change --email to --mailto and I would like any feedback on that (or anything else). The big stumbling block for me is working out how to put in a command that will go to somewhere like /usr/bin or C:\Strawberry\site\lib. Any pointers to docs on this would be extremely helpful.

Regards,

John Davies

Update: I've now deleted the repository. The code has moved on & will shortly appear on CPAN, unless something strange happens. I'll post here when it's released, but if anyone really wants the repository back, I'll put it back up in response to a post or /msg.

If your program installs into the path as the file named "ipchange" then it is an appropriate name. However, that name seems to imply that it changes IPs, which does not match your description. Maybe "ipmonitor" or "ipchangemon" or "ipwatchd"? Anyway, my preferred way to release apps is to have a module (lib/X.pm) and then a script (bin/x) which parses the command line (Getopt::Long + Pod::Usage) and invokes that module. This way people get both interfaces (module+command). In a perl dist, the binary would usually be "bin/x.PL" until processed by MakeMaker to become installed as "bin/x". If the dist is not just a shell command, I think maybe a mixed case name is appropriate.