Give Me MetaCPAN

Ever since MetaCPAN launched I’ve been getting increasingly irritated with people who still use links to search.cpan.org. Isn’t it obvious that MetaCPAN is better? Why do people still insist on sharing links to the older site?

Of course they do it for various reasons. Perhaps they aren’t as in touch with the modern Perl world as I am. Perhaps they are wary about changing to use the new shiny toys because they know that a newer shinier one will be along soon. Perhaps I’m reading a web page from five years ago and they can be forgiven for not linking to a site that didn’t exist at the time.

Eventually I realised that there was no point in getting annoyed. I had a computer. Surely I could do something that would fix this problem.

My first idea was to write a GreaseMonkey script. Then I realised that would be hard. MetaCPAN and CPAN have slightly different URL schemes. I’d need to recognise a CPAN URL and convert it to the equivalent MetaCPAN URL. Not an impossible task at all, but not something I could knock up in an hour or so. Especially not in Javascript.

So I asked on the #metacpan IRC channel. Surely I couldn’t be the first person to have this problem. And someone there introduced me to mcpan.org. There’s no point in clicking on that link. You’ll just end up on MetaCPAN. Because that’s what mcpan does. It’s a URL rewriting service. You give it a CPAN URL (with the cpan.org changed to mcpan.org) and it redirects you to the equivalent page on MetaCPAN.

That’s the hard bit of the problem. The bit I didn’t want to write. And someone else has already written it. But they seem to have kept it very quiet. This deserves more publicity. I wish I could remember who wrote it. If you know, please leave a comment.

So we’re now most of the way there. Now if I click on a CPAN link, I can just edit the location bar to add an ‘m’ and I’ll be redirected to the right place. But we can do better than that. I’d like to be automatically redirected. That’s when I discovered the Redirector extension for Firefox. Once it’s installed you can configure it to redirect certain URLs to other ones. I have it configured so that http://search.cpan.org* redirects to http://mcpan.org$1. See how you can use wildcards to match URLs and then use whatever they matched in the replacement URL. It’s a lot like regexes in Perl.

And we’re done. Now whenever I click on an old-style CPAN link, I’m automatically redirected to mcpan, And that, in turn, redirects me to MetaCPAN. And, best of all, I didn’t have to write any code. It was just a case of putting together tools that already existed.

I did all this a few months ago. I meant to write this blog post at the time, but I forgot. I was reminded this morning when Chisel mentioned a GreaseMonkey script he had written to do all of this. See, Chisel isn’t afraid of parsing URLs in Javascript like I was. He just went ahead and did it.

But having alternative solutions to the problem is good, right?

Update: I’ve just been talking about this on the #metacpan IRC channel and it seems that I was rather misunderstanding what was going on here. Here are the details.

Firstly, it was dpetrov who told me about mcpan.org. It’s his domain. I asked him for the code, and he pointed out that there is no code. mcpan.org just redirects everything to a domain called sco.metacpan.org which is where the magic happens. He just got tired of editing search.cpan.org to sco.metacpan.org so he registered another, simpler, domain.

So the actual cleverness happens over on sco.metacpan.org. And that’s really just a list of rewrite rules (the code is on github). I say “just”, but I still wouldn’t want to write them myself.

All this means that mcpan,org is only a convenient tool for when you’re manually editing your location bar. When you’re using the Redirector extension for Firefox you can miss out the middle man and redirect straight to sco.metacpan.org. So I’ve updated my Redirector rule appropriately.

XML::Feed

XML::Feed is the module that does most of the heavy lifting for Perlanet and, as such, it powers some important parts of the Perl community’s infrastructure. Unfortunately, for a while now it’s had a rather long list of outstanding bugs that weren’t getting fixed.

Sometime last year, Matt Trout got co-maintainership on the module and shortly afterwards he shared it with me. I released a couple of versions last year (largely to fix one particular and important bug) and fixed a few of the easier bugs on the list, but most of the list remained untouched.

Whilst working on these few fixes I set up a copy of the repository on Github. And about a month ago, that started to pay dividends as I got a couple of pull requests from Gabor. In combination with a couple of new bug reports that came it at about the same time, this galvanised me into putting a bit more effort into the module.

I’ve released a couple of new versions in the last week. Most importantly, I think that version 0.48 fixes the test failures that were common in the last few releases – and initial indications are that I’m right.

It seems that people are interested in this module. So let’s see if we can get a little community going. I’ve set up a mailing list to discuss the module and. of course, there’s already the bug list and the Github repository.

Patches welcome. Github pull requests even more so. But if you just have ideas and suggestions or want advice on how to use the module, I’d love to hear from you.

Fedora and Centos CPAN RPMs

Today I’ve updated my spreadsheets of the CPAN modules that are available as RPMs from various repositories for Fedora and Centos. I see that in many cases the “official” repos are now more up to date than my own repo (which I originally set up because the official repos are sometimes out of date).

This is all a precursor to doing a lot more work on my repo. I need to know which RPMs are being kept up to date by other people so that I can ignore those modules.

But I thought that other people might find the data useful or interesting.

Net::Songkick

Sometimes it’s good to just take a new idea and hack on it for a couple of hours to see what happens. That’s what I’ve done this evening.

I’ve been using Songkick for a while. Songkick is a web site that tracks users’ attendance at gigs. I’ve been tracking the gigs I’ve been going to as well as trying to fill in over thirty years of old gigs.

I’ve known for some time that Songkick has an API, but until yesterday the API has been for invited partners only. But yesterday on Get Satisfaction they announced that it was now public.

The public API doesn’t do that much yet. There are only four documented calls. But it’s already useful and I’m sure it will gain more functionality quickly.

And this evening I’ve spent some time writing a very simple Net::Songkick module. This is really just a proof of concept, but I’ve got big plans for improving it. And I can already write a useful program like this:

If you have any interest in gigs then I highly recommend Songkick to you. And if you like attending gigs and hacking Perl (although not necessarily at the same time) then why not give Net::Songkick a try. All you’ll need is an API key from Songkick.

There’s a Github repository too; if you feel like hacking on it…

Learning About Traits

I’ve been teaching basic Moose in my training courses for several years now. And, as I’ve mentioned before, I’ve been slowly converting some of my CPAN modules to use Moose. But there are still bits of Moose that I haven’t really needed to get to grips with.

One such area is Moose’s support for Traits. Oh, I knew vaguely what they were and I understood why you might use them. But I’d never implemented a system using traits, so my knowledge about how you’d actually use them was a bit shaky to say the least.

But over the last few days I’ve learned quite a lot about how to use traits. And I’ve had to learn it pretty quickly.

It all started a few weeks ago when I got a github pull request from Oliver Charles. Oliver had taken a fork of my Perlanet repository and had massively refactored the codebase so that all the clever bits were implemented as traits.

What this means is that the core Perlanet code is pretty dumb. In order to do anything really useful with it to need to add in some traits. There are traits to read the configuration from a YAML file, traits to carry out various kinds of cleaning of the input and a trait to produce the output using the Template Toolkit. There are also traits to handle caching and OPML generation. All in all it makes the code far nicer to work on.

Oh, and there’s a Perlanet::Simple module which uses all of the traits required to implement the Perlanet behaviour that users currently expect.

There were a few problems with Oliver’s initial version. Some of the dependencies weren’t quite right. But we soon fixed that and last week I finally released Perlanet 0.47 which implemented these changes.

Then I installed it on the server which hosts most of my planets. And everything broke.

So I’ve spent a lot of the weekend fixing these issues. Part of it was that Oliver’s changes assumed some configuration file changes that I hadn’t implemented. I changed his changes so that they worked with the existing configuration settings (we don’t want users having to change configuration files unnecessarily). Other changes were harder to track down. I particularly enjoyed one where no feeds were fetched unless the user turned on OPML support. I learned a lot about how traits worked by tracking that one down.

But it all seems to be fixed now. Perlanet version 0.51 is available on CPAN and it will hopefully be a lot easier to customise to your needs. I hope we’ll see a number of other Perlanet traits appearing over the next few months.

And, most importantly, I’ve learnt a lot about traits. I think I understand them now.

If you want to learn traits, I can highly recommend asking someone to implement traits in one of your projects. And it’s even better if they do it in a slightly broken way so that you need to debug it.