After some experimentation I discovered the key difference between putting scripts in /bin vs /scripts: the installer Dist::Zilla creates will install scripts it finds in /bin into the perl/site/bin directory, but it doesn't do that for /scripts. It also automatically generates .bat files for them on Windows. I haven't checked Unix, but it wouldn't surprise me if it generates files without the .pl extension and sets the executable permission on them.
This actually suits my use case. I built ghcn_fetch.pl to be general purpose (albeit for a very specific application) so anyone interested in climate data could use it find weather stations of interest and to retrieve daily or summarized data from NOAA GHCN and easily analyze that data in Excel or other tools. So, when I install Weather::GHCN I want it to install the ghcn_*.pl scripts in site/bin so I can execute them.
Is this not reasonable? Is there a better or more preferred way?
As a side note, the scripts are really just a thin wrapper that uses a like-named module (e.g. ghcn_fetch.pl uses Fetch.pl) and calls its run() sub, plus a lot of POD. I've currently put these app modules in App::GHCN. But now I'm wondering if that's the right approach.
My original vision was to have module GHCN and application scripts ghcn_fetch, ghcn_extremes and ghcn_station_counts all show up in CPAN when you search for GHCN. Now I'm thinking there are two ways to package this stuff:
Plan A
1. Weather-GHCN will be the package name, and it will contain lib Weather/GHCN and the .pm files for the GHCN modules.
2. The app modules Fetch.pm, Extremes.pm and StationCounts.pm could live there too, or maybe in an App subfolder (e.g. use Weather::GHCN::App::Fetch inside ghcn_fetch.pl)
3. The ghcn_*.pl scripts go in a /bin folder so they'll be installed in site/bin
The downside to this plan is that I don't think that ghcn_fetch et al will show up in cpan at all. The POD in the GHCN modules documents the API. The POD in ghcn_fetch documents the application and how one would use it. If someone is looking for a tool to extract and analyze climate data, I want them to find ghcn_fetch and read it's POD, not the POD for any of the GHCN modules. They only need that to build their own tool.
Plan B
1. same as Plan A
2. same as Plan A
3. The ghcn_*.pl scripts are each packaged separately: App::ghcn_fetch, App:ghcn_extremes, and App:ghcn_station_counts
The advantage to this plan is that the ghcn scripts will show up in a cpan search and, perhaps more importantly, the documentation will be picked up from the script and be a lot more meaningful than the POD for a GHCN class API. So, I'm leaning in this direction.
Your feedback on these plans, and other suggestions, would be much appreciated.
Thank you for your time on this matter. You've been a real help. I've been programming off and on in perl for years, am retired now, and it's become something of a hobby. I'm a neophyte when it comes to cpan though, and I'd like to start giving back to the community so I plan to put your help to good use.
- Gary
P.S. I considered using Weather::NOAA for GHCN, but when I tried emailing the owner of the modules in that namespace email failed. Apparently lbecchi@cpan.org is no longer a valid email. I also downloaded the module Weather::NOAA:GFS, which is from 2004, and discovered that the servers it accesses do not respond to ping. The code is likely quite out of data. So, I didn't want my code coexisting with a couple of defunct modules in the ::NOAA subspace.
