[Pdx-pm] Starting from scratch with Module::Build

Marvin Humphrey marvin at rectangular.com
Sat Jul 2 14:52:21 PDT 2005


On Jul 1, 2005, at 7:06 PM, Michael G Schwern wrote:

> Slowing the flow of modules to CPAN is not the way to do that  
> espcially if
> its slowed by having to know some mysterious module creation  
> mantra.  That
> does not select for the best authors but for the ones that slog  
> through the
> lore to discover what the mantra is.

True.  I am recalling how confusing I found it to prepare my first  
distro.  It didn't help that I was contemplating a multi-module  
distribution right off the bat.

> I've seen a lot of excellent code that was not put on CPAN because  
> either
> A) they thought it was a difficult thing to do or B) they thought  
> putting
> code on CPAN was something "special" and that nobody would be  
> interested
> in their module.
>
> Remember, CPAN is the *Comprehensive* Perl Archive Network which  
> means you
> get the good and the bad.  Often by trying to filter out the bad  
> we've lost
> the good.  Its better to just gather everything together and filter  
> from
> there.

Agreed.

Since I consider undocumented code worthless and poorly documented  
code to be a timesuck I can't afford, I'd prefer never to see  
inadequately documented contributions in my search results.  I have  
similar opinions about code with no tests at all.  However, if a  
search-time filter can be constructed to weed out stuff like that,  
then there's not as much to be lost by relaxing expectations, and if  
that gets some people over the hump and turns them into contributors,  
they may well end up contributing valuable material down the line.

I can also see that the punitive approach of ridiculing poor  
documentation has a downside, in that it may intimidate potential  
contributors.  If rewarding good documentation were as effective, it  
would be better to go that route.

>>>> As someone who takes documentation and QC seriously, I appreciate
>>>> having a template prepared for me that errs on the side of excess.
>>>>
>>>
>>> This I don't understand.
>>>
>>
>> I don't find it burdensome to delete a couple lines of "I'm too lazy
>> to write POD" POD, because I'm going to spend a *lot* more time
>> writing good POD to replace it than it takes to hit the 'd' key a
>> dozen times in vim.  I'm going to check the module and its associated
>> files over several times to make sure nothing's missing before I
>> publish.
>
> If you're going to delete it why have it there in the first place?

It's a "placeholder".

What's hard to understand about that?  It's not like I'm the only  
person who finds starting from a template more convenient that  
starting from an empty directory.  Grokking a template imparts  
confidence that you've grokked the totality of the problem.  When  
trying to follow the path you advocate away from the MakeMaker system  
I'd already learned and was comfortable with, I went looking for a  
Module::Build template to work from, because I figured that if I  
could understand and edit every part of the template, I'd have done  
everything that absolutely had to be done.  When I couldn't find the  
procedure for creating such a template anywhere in the Module::Build  
docs, I almost threw in the towel and went back to MakeMaker.

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/



More information about the Pdx-pm-list mailing list