brian d foy

My second day of CPAN Cleaning was just the sort of work that I like: organizing a chaotic mess into something I can work with. My CPAN distributions are a mix of almost everything I've done in my history as a CPAN author. There was a CVS repository in the mix, several things left over from Sourceforge, and various ways of using Git. Even in the Git repos, many files still had CVS tags. A surprising number of files don't end in a newline, making for apparently pointless file changes.

Fixing all that up is easy; it's just work.

But then I want to ensure that all the .gitignore files have everything they need. In some repos, some .DS_Store entries snuck in, for instance. For MANIFEST.SKIP, we have a default set of includes. I went looking for the same thing for Git, and, of course, Github has a repo of sample .gitignore for many languages.

The fun came in when I wanted to work with all the repos at once. I won't bother to show my scripts (decidedly non-modern) to go through each, adjust a few things, commit the changes, and then push those. Some of that pain was changing all the origins to GitHub. But, I like that sort of work, which is why I like helping people with legacy code. I couldn't automate that stuff because every repo is a snowflake. Many had changes but were behind the source in GitHub, usually because I had merged pull requests.

That took all day, so I had to spend the night working on what might be a not so interesting idea: CPAN::Critic, to check all the things that I need to do to all of my repos. I figured it would be like Perl::Critic, but for CPAN distributions. I thought about adapting Module::CPANTS::Kwalitee, but having worked with that module before, I think I'm doing something different. I have more ephemeral things to check and I'm not interested in kwalitee as much as To Do. I started to fork Perl::Critic, but that was heavily focused on stuff that looks at code. If I want to do that, I'll just use Perl::Critic.

My CPAN::Critic fun (and sometimes reinvention is just a hobby) comes from what I've done with some of the Perl books. Most everything I write is Pod, so I'll write a bunch of tiny programs on the side to check the Pod. Some of that is structure, but it's also prosaic things like writing "toward" instead of "towards" everywhere, or writing the Perl version in the same format everywhere. It wasn't as sophisticated as Dave Cross et alia writing the Template Toolkit book in Template::Toolkit, but it's quick and it works.

All that work distracted me from the other tool I want to write: the ubergit. I want something to manage multiple repos with one command. I could push to origin for 200 repos without visiting any of them. For the small tasks, that's just some automation. But, imagine adding an entry to every gitignore, committing it, and pushing using a single command using less than 50 characters.