<div dir="auto">Re: Acme module, how about a python minifier? Guaranteed to make your python code run faster!  </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 13, 2020, 11:37 AM Jon Gentle <<a href="mailto:atrodo@atrodo.org">atrodo@atrodo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good Morning,<br>
<br>
That is generally the process I use as well, so I'm thinking we can<br>
use it as a general flow of how to structure the virtual meeting. I am<br>
thinking that we could go through the whole module creation process,<br>
from start to finish, as a collaborative effort during this virtual<br>
meeting. Creating an Acme module would be great for that, so we can<br>
spend our time on the module creation process instead of the code<br>
itself. It sounds like answering the question of how do you create a<br>
proper perl module has enough interest for us to meet next Wednesday.<br>
I'll get that scheduled and let everyone know how to join.<br>
<br>
Does that sound good to everyone? In the meantime, if anyone has any<br>
ideas for a good Acme module to create, I'd love to hear the idea.<br>
<br>
-Jon Gentle<br>
<br>
On Mon, May 11, 2020 at 12:54 PM Michael Conrad <<a href="mailto:mike@nrdvana.net" target="_blank" rel="noreferrer">mike@nrdvana.net</a>> wrote:<br>
><br>
> If you’re going virtual, I can join!<br>
><br>
> I have a pretty minimal effort sequence I use when creating new modules:<br>
>     * write a package in a lib dir, with a nice pod synopsis and description<br>
>     * write a test case in a t dir (maybe just loading the module to check for syntax erors, or call a few simple functions)<br>
>     * copy dist.ini from a previous project<br>
>     * edit the names in dist.ini to match the new project<br>
>     * check into git (because my dist.ini depends on git)<br>
>     * dzil test<br>
>     * dzil release<br>
><br>
> 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.<br>
><br>
> > On May 9, 2020, at 11:24 AM, Ernst, Kevin <<a href="mailto:Kevin.Ernst@cchmc.org" target="_blank" rel="noreferrer">Kevin.Ernst@cchmc.org</a>> wrote:<br>
> ><br>
> > On 09.05.20 at 00:12, Scott R. Corzine wrote:<br>
> >> Why don't we do both: this month start that collaborative basic perl<br>
> >> module and next month do all of the bits and pieces around it needed<br>
> >> to turn it into a respectable perl module.<br>
> ><br>
> > Agreed, this sounds great. Especially the "respectable" part.<br>
> ><br>
> > All I've been able to discern about Perl modules is that there's a<br>
> > 'package' somewhere in the middle, and they have to have '1;' at the<br>
> > end, and that is so just Perl in a nutshell.<br>
> ><br>
> > Look, I'm 50% joking here; I /have/ written Perl modules in a work<br>
> > context. I just never felt like I was doing it right. Maybe I'm just a<br>
> > weak/inexperienced developer who needs the hand-holding, but just seeing<br>
> > how someone who knows what they're /doing/ would structure a module from<br>
> > scratch would still be super-helpful.<br>
> ><br>
> > Even if it's something facile and completely throwaway, like Yet Another<br>
> > Template Processor, or Yet Another Command-line Weather-fetching Client.<br>
> ><br>
> > Where to *put* them on a local system or shared server environment is a<br>
> > whole other question. Like, should they go in<br>
> > /usr/local/perl5/lib/perl5/5.28.1/site_perl, or<br>
> > /usr/local/perl5/lib/perl5/5.28.1/linux-x86_64/lib/perl5/…, or, aw hell.<br>
> > Where are they /supposed/ to go? Where do I put a module that will just<br>
> > *work* with Perl 5.something?<br>
> ><br>
> > —Kevin<br>
> > _______________________________________________<br>
> > Cincinnati-pm mailing list<br>
> > <a href="mailto:Cincinnati-pm@pm.org" target="_blank" rel="noreferrer">Cincinnati-pm@pm.org</a><br>
> > <a href="https://mail.pm.org/mailman/listinfo/cincinnati-pm" rel="noreferrer noreferrer" target="_blank">https://mail.pm.org/mailman/listinfo/cincinnati-pm</a><br>
> _______________________________________________<br>
> Cincinnati-pm mailing list<br>
> <a href="mailto:Cincinnati-pm@pm.org" target="_blank" rel="noreferrer">Cincinnati-pm@pm.org</a><br>
> <a href="https://mail.pm.org/mailman/listinfo/cincinnati-pm" rel="noreferrer noreferrer" target="_blank">https://mail.pm.org/mailman/listinfo/cincinnati-pm</a><br>
_______________________________________________<br>
Cincinnati-pm mailing list<br>
<a href="mailto:Cincinnati-pm@pm.org" target="_blank" rel="noreferrer">Cincinnati-pm@pm.org</a><br>
<a href="https://mail.pm.org/mailman/listinfo/cincinnati-pm" rel="noreferrer noreferrer" target="_blank">https://mail.pm.org/mailman/listinfo/cincinnati-pm</a><br>
</blockquote></div>