Perlhacks Code Dashboard

Culling My Modules

About a year ago, I dabbled briefly with Travis CI. I even gave a talk about my experiences. The plan was that I would start to use it for all of my code. But real life intervened and I never got round to getting any further with that project.

This weekend, I finally made some progress. I added a .travis.yml file to all of my Github repositories that hold CPAN modules. I even fed the details through to Coveralls so I getย test coverage reports. From there it was a simple step to building a dashboard that monitors the health of all of my CPAN modules.

And it’s not a pretty picture. You’ll see a lot of grey boxes on that page, indicating that Travis couldn’t run the tests or, worse, red boxes showing that the tests failed for some reason.

Yesterday I made a few quick fixes to some of the modules (particularly in the WWW::Shorten namespace) and a couple more of them now work. But I want to work out how much effort it’s worth investing in the ones that are still failing. And, widening my scope a little, I’ve decided to take a close look at my CPAN modules and work out which ones are worth keeping and which ones I should just delete.

For example, twelve years ago I was really excited about the idea of AudioFile::Info. Most people were ripping music to MP3s, but I wasn’t following the crowd and was using Ogg Vorbis instead. AudioFile::Info and its friends was an attempt to make it easy to extract information from audio files no matter which format they were it. I suppose it was a kind of DBI for ID3 tags. But twelve years on, does anyone really care about that any more? I switched all of my music collection to MP3 years ago. If I recall correctly, the AudioFile::Info modules use a convoluted hand-crafted plugin system which never worked as well as it should. I could probably switch them to use some kind of plugin architecture from CPAN. But is it worth the effort?

Then there is Guardian::OpenPlatform::API – a Perl wrapper around the Guardian’s API. I believe they changed the API end-point several years ago so the module doesn’t even work. But the fact that I’ve had no complaints about that, probably indicates that no-one has ever used it.

It’s a similar story for Net::Backpack. To be honest, I have no idea whether or not it still works. Is Backpack still running? Ok, I’ve just checked and they’re no longer offering it to new customers. But if I’m not a paying customer is there any way I can test that it still works?

Finally, there is the WWW::Shorten family of modules. I released a module called WWW::MakeAShorterLink back in 2002, but it was Iain Truskett who realised that there should be a family of modules around the (at the time new) URL-shortening industry. I took over the module when Iain passed away and I’ve been maintaining it ever since. But it’s a real pain to maintain. The URL-shortening industry changes really quickly. For a long time, new services were popping up all of the time (and many of them closed down just as quickly). I haven’t been anywhere near quick enough at releasing versions that keep up with all the changes. I suspect that at least a couple of the current test failures are down to services that have closed down. I should probably investigate those over the next few days.

I don’t think WWW::Shorten is in any danger of going away (but I need to find a better way to keep abreast of changes in the industry) but the other modules I’ve mentioned here (AudioFile::Info::*, Guardian::OpenPlatform::API and Net::Backpack) are on borrowed time. If you’re using them and you’d like to see new versions of them in the future then let me know. If you’d like to take over maintenance, then that would be even better.

If I don’t hear from anyone (and I strongly suspect that I won’t) then I’ll be removing them from CPAN in a couple of months time.


Also published on Medium.


Posted

in

by

Tags:

Comments

7 responses to “Culling My Modules”

  1. Gabor Szabo Avatar

    Wouldn’t it be better to just mark them as “looking for maintainer” and leave them on CPAN? (Thought I don’t know how would you mark them without uploading a new version. Maybe MetaCPAN should have some way to do so.

    1. Dave Cross Avatar

      Ah yes. I forgot to mention that. All of the modules mentioned above are already marked as “HANDOFF” on CPAN.

  2. Jakub Narebski (@jnareb) Avatar

    Culling Net::* and *::API modules that do not work because service is no more, or its API changed (and they retired old API or do not use versioning) is a good idea. Culling other – not so much.

  3. Ken Williams Avatar

    I strongly suggest not deleting them from CPAN (ever!), but just marking them as unmaintained. Deleting code is the ultimate in backward incompatibility, a real slap in the face to whoever’s unfortunate enough to be using it. The only user for whom it really matters is someone using these modules in legacy mode, and deleting them just makes their hard luck even harder.

    WRT hoping to hear from people who use the modules, don’t count on it – it’s exceedingly rare to ever hear from users of even frequently used modules, even though clearly those people exist. I would never think I have to read someone’s blog regularly for years just in case they announce they’re going to delete their code from CPAN and I would have reservations about ever using their stuff again, it would piss me off so much.

  4. […] July I wrote a post threatening to cull some of my unused CPAN modules. Some people made sensible comments and I never got round to […]

  5. […] Culling my CPAN modules (perlhacks.com) […]

  6. […] a year ago, I wrote about the dashboard I had written for my CPAN modules. Itโ€™s a simple page that pulls together […]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.