Reflections on porting Planet

I use the Python Planet software to generate the RSS feed and static site  for planet.tech-artists.org, like is done for planet.python.org. I’ve been using it for several years and recently got the urge to do some open source work, so I “forked” the original Planet code (actually, the Bazaar repo is no longer so I just worked off the tar) and began to port it to use Jinja2 instead of the HTML templating engine derived from Perl. I am mostly done and just need to clean out a few more planet.tech-artists.org specific things before linking to the github repo here, but I did have some interesting reflections on porting code that is 7.5 years old!

• All the dependencies were just copied in. This was before the popularity of pip. Was this a common way to do dependency management back then (how widely used was easy_install)?
• In some cases it was difficult to know what was part of planet and what was copied in. I’ve replaced what I could with a requirements.txt. feedparser is still maintained, sanitize is kindly provided on PyPI, and the other modules were provided for way old compatibility, so now only htmltmpl is copied in.
• The standard library is way better nowadays. This code ran on 2.1 or 2.2 (conflicting comments to which is the minimum). No socket.setdefaulttimeout, no logging module. I guess the backwards compatibility situation is even worse nowadays though, which code often having to support 2.5 to 3.4!
• The code was still pretty good on every level. Structurally it is well thought out. Surprising to me was that stylistically it was still pretty good as well, aside from missing use of new language features (for example: context managers, ‘in’ keyword).
• It did a lot of stuff, especially via configuration, that I can’t imagine anyone uses. In fact Planet is really an entire static site generator. Maybe people used it for that in 2006? Anyway, nowadays there are so many better options, Planet is only used for pages like Planet Python and Planet TechArt, so I took out unnecessary configuration which simplified things greatly. And of course I dropped the compatibility modules that are no longer needed, and the planet-cache.py utility which I never used.
• It had “unit” tests! And they used the unittest module! But I couldn’t get them to work (and they’re now entirely broken). It even had a script to run all of them, though nowadays I guess everyone uses test runners, thank goodness.
• Looking over the HTML templating engine code wasn’t the first time I’ve felt uncomfortable reading code, to later find out it was ported from Perl. Perl systems stand out like a sore thumb! I was very happy to get Jinja2 working. I actually don’t have complaints with htmltmpl.py/HTML::Template, but it isn’t what I want to be using in 2014.

I work every day in a Python codebase originally written in the early 2000’s, so I’m not stranger to legacy systems. But that is “enterprise” code which is different from open source packages, and I wasn’t writing Python in 2006, so it is interesting to get a glimpse into what the Python world was like 7.5 years ago. Kudos to the original authors for doing a great job.