[Cincinnati-pm] May cinci.pm status

[Jon Gentle]

Good Morning,

That is generally the process I use as well, so I'm thinking we can
use it as a general flow of how to structure the virtual meeting. I am
thinking that we could go through the whole module creation process,
from start to finish, as a collaborative effort during this virtual
meeting. Creating an Acme module would be great for that, so we can
spend our time on the module creation process instead of the code
itself. It sounds like answering the question of how do you create a
proper perl module has enough interest for us to meet next Wednesday.
I'll get that scheduled and let everyone know how to join.

Does that sound good to everyone? In the meantime, if anyone has any
ideas for a good Acme module to create, I'd love to hear the idea.

-Jon Gentle

On Mon, May 11, 2020 at 12:54 PM Michael Conrad <mike at nrdvana.net> wrote:
>
> 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
> _______________________________________________
> Cincinnati-pm mailing list
> Cincinnati-pm at pm.org
> https://mail.pm.org/mailman/listinfo/cincinnati-pm