The typical end-user of your CPAN distribution wants a handy command they can run to report IP address changes, and doesn't really care how it's implemented. Is that right?

If so, the principle of least astonishment suggests your distro should install a well-named command, with a clear usage screen, in the conventional CPAN way.

A widely used example of such a (non-modulino) distribution that springs to mind is Perl-Tidy, which installs a perltidy command in the conventional way for each platform. I've happily used this command for years without caring how it's implemented. Looking at it now, I see it's essentially a one-liner:

exit Perl::Tidy::perltidy( argv => $arg_string );
[download]

I (think) I have something similar to what you're trying to do. It's a module. I, like others, like to keep modules and binaries separate. In all my distributions that require a user usable binary, I just add it in so it gets installed. To do so, I do this in the Makefile.PL script:

my %WriteMakefileArgs = (
    NAME             => 'Addr::MyIP',
    AUTHOR           => q{Steve Bertrand <steveb@cpan.org>},
    VERSION_FROM     => 'lib/Addr/MyIP.pm',
    ABSTRACT_FROM    => 'lib/Addr/MyIP.pm',
    LICENSE          => 'artistic_2',
    EXE_FILES        => [qw(bin/myip)],
    ...
[download]

... see the last line? That will install the distribution's myip binary located in the distribution's bin directory into their path.

fwiw, I wrote that distribution (which fetches my devices public IP address) so that I can maintain VPN connections on the locations I have equipment even if they have dynamic/changing addresses.

I call that code from the update-ip binary in my Net::DNS::GoDaddy library, which then updates certain DNS A records for me through GoDaddy's API, so all of my locations are always up-to-date with their current public IP address. I can always use 'home.domain.com' for my home VPN connection etc.

Having the two files separate also makes it easier for others to hack at them, and for me to review the patches or pull requests. Documentation is separate, tests are separate, less chance I break one and not the other, and it doesn't have the feeling like there's executable code inside of a library. A library is to be read, not executed (imho), and executing a .pm file just seems so very wrong.

G'day John Davies,

Without any code, it's not really possible to make many comments about this. I would question why you thought a modulino was appropriate.

"Is App:ipchange a sane name?"

My preference is to use capitalised strings for each element of the module name: with the information presented, I'd prefer App:IPchange; with additional information, I might prefer something else. :-)

It's good that you've asked about this before publishing to CPAN. If your code exists in some public 'git' repo (or similar), that would be helpful in making further (informed) comments.

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

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.

Further to stevieb's excellent advice, a few more references in case they're useful. I'm assuming you'll be creating a Makefile.PL manually using ExtUtils::MakeMaker.

For uploading your first CPAN distribution, I really like Re: What do I use to release a module to CPAN for the first time? by davido (cited at Writing Solid CPAN Modules) ... which urges you to stay away from Dist::Zilla until you understand every step involved in doing it manually (though that ship might have sailed already ;-).

• ExtUtils::MakeMaker (EXE_FILES is a ref to an array of executable files to be copied to the INST_SCRIPT directory)
• Makefile.PL of ExtUtils::MakeMaker (Perl Maven)
• Install scripts using ExtUtils::MakeMaker (SO - see especially first response from "multi-site ikegami")

Looking forward to seeing your first of many CPAN distributions! :)

Despite the warning, I'm planning to use Dist::Zilla. This is because I was lured into using it about 6 years ago at a London PM meeting when I talked about, and later released, XML::Lenient with lots of help from the monastery (XML::Lenient - my first CPAN module). I certainly don't understand every step, especially across operating systems, but I have enjoyed learning about computers for nearly 50 years, despite the various pain points. I learn better when I see a need for the knowledge, so this may be my big chance. :-)

Regards,

John Davies

Oops, I missed your first CPAN contribution XML-Lenient of 2016. Sorry 'bout that.

I see you used SemVer in your first module. Feel free to ignore my warning to steer clear of SemVer for your second one :) - see Re: Sane deprecation policy for a CPAN module? (Software Versioning References) for why.

You might also be interested in this recent thread from new CPAN author PUCKERING.