I first started the adoption list because I thought that we (the Perl community) needed a way to identify CPAN distributions that were in need of some TLC. One of the key factors used to build the list is whether a dist is being used by other CPAN dists. Today I released a new version of Text::Levenshtein, which is used by 4 other dists. I initially imagined I might just fix a couple of the outstanding bugs, but ended up shaving quite a bit more of the yak.

Sometimes I adopt modules because I start using them. I think you need to look into, and after, the modules you depend on. MIYAGAWA's Time::Duration::Parse was a recent example.

Sometimes I adopt modules to fix problems with the distribution. I adopted Chatbot::Eliza so I could fix the abstract.

And sometimes I adopt modules just because.

In a number of previous jobs I've done a lot of processing of natural language text, and have used Text::Levenshtein once or twice, and pointed it out to others. And it's used by four other distributions, so I decided it was time to see if I could adopt it. Yes!

When I adopt a module I start off by 'modernising' the distribution. Getting it 'CPANTS clean' is a good start, but here are the things I generally do:

Ensure the metadata and doc specify the license type, confirming with the original author if it's not clear.

Specify the minimum version of Perl, both in code and metadata.

Make sure all pre-requisite modules are listed in the metadata.

Put in place the usual directory structure. A lot of old dists have everything in the top directory, so I add lib/ and t/ , for example.

and , for example. Make sure the dist has up-to-date metadata file(s).

Add the github repo to the metadata and a link to it in the pod.

Find all competing / similar modules and list them in the SEE ALSO section.

Reformat the Changes file as per CPAN::Changes::Spec, or in some cases add a Changes file, getting the dates of previous releases from BackPAN.

All modules and scripts use strict and warnings.

Fix any pod errors (found with podchecker).

Fix any typos that David Steinbrunner has reported (thanks, David!).

Try and fix at least some, or preferably all, of the outstanding bugs.

Move the testsuite to Test::More and flesh out the testsuite with at least the common use cases.

Look at CPAN Testers results, and try to deal with any failures. I'm struggling here with one recent adoption.

I've noticed that I'm gradually being pulled into the Dist::Zilla club. I previously tried switching to it a couple of times, but found it very frustrating (which I assume is more about me than DZ, given the serious authors who use it). Having adopted a number of distributions recently though, I'm finding that switching the dist to DZ makes my life a lot easier: a number of the points above are handled for you.

Back to Text::Levenshtein. Having done a lot of the basics, I started looking at the bugs, and then at the code. Generally I try to take it easy at first, minimising the scope of my refactorings. But after struggling with it for a while, and then reading the wikipedia page on Levenshtein, I rewrote the whole module, based on one of the algorithms presented in pseudocode on wikipedia. That's a first for me, but it felt like the best way to deal with some of the bugs.

This might not be a very widely used module, but it feels good to fight against CPAN entropy. Plus I learned a bit about edit distance metrics.

I'd like to acknowledge DREE who first released Text::Levenshtein, and JGOLDBERG who maintained it from 2004 to 2008. I'm the third custodian, but probably won't be the last.

Are any of the modules you use candidates for adoption?

Please enable JavaScript to view the comments powered by Disqus.

Disqus