[Cincinnati-pm] May cinci.pm status

[Michael Conrad]

If you’re going virtual, I can join!

I have a pretty minimal effort sequence I use when creating new modules:
    * write a package in a lib dir, with a nice pod synopsis and description
    * write a test case in a t dir (maybe just loading the module to check for syntax erors, or call a few simple functions)
    * copy dist.ini from a previous project
    * edit the names in dist.ini to match the new project
    * check into git (because my dist.ini depends on git)
    * dzil test
    * dzil release

The effort of getting that first dist.ini is mostly about deciding what workflow you want to use and what workflows Dist::Zilla can support.  My prefs are to have dzil rewrite the pod and version of the module before packaging it, and use git tags to track versions, and various other opinions.

> On May 9, 2020, at 11:24 AM, Ernst, Kevin <Kevin.Ernst at cchmc.org> wrote:
> 
> On 09.05.20 at 00:12, Scott R. Corzine wrote:
>> Why don't we do both: this month start that collaborative basic perl 
>> module and next month do all of the bits and pieces around it needed 
>> to turn it into a respectable perl module.
> 
> Agreed, this sounds great. Especially the "respectable" part.
> 
> All I've been able to discern about Perl modules is that there's a 
> 'package' somewhere in the middle, and they have to have '1;' at the 
> end, and that is so just Perl in a nutshell.
> 
> Look, I'm 50% joking here; I /have/ written Perl modules in a work 
> context. I just never felt like I was doing it right. Maybe I'm just a 
> weak/inexperienced developer who needs the hand-holding, but just seeing 
> how someone who knows what they're /doing/ would structure a module from 
> scratch would still be super-helpful.
> 
> Even if it's something facile and completely throwaway, like Yet Another 
> Template Processor, or Yet Another Command-line Weather-fetching Client.
> 
> Where to *put* them on a local system or shared server environment is a 
> whole other question. Like, should they go in 
> /usr/local/perl5/lib/perl5/5.28.1/site_perl, or 
> /usr/local/perl5/lib/perl5/5.28.1/linux-x86_64/lib/perl5/…, or, aw hell. 
> Where are they /supposed/ to go? Where do I put a module that will just 
> *work* with Perl 5.something?
> 
> —Kevin
> _______________________________________________
> Cincinnati-pm mailing list
> Cincinnati-pm at pm.org
> https://mail.pm.org/mailman/listinfo/cincinnati-pm