POSTS

Migrating from Pelican to Hugo

As you’ve realized from the drastically different look, the site has gotten an overhaul, and I’ve replaced Pelican with Hugo. There was a variety of reasons I made this switch, and to be clear, Pelican is still a fine way of going about making statically-generated sites. But there was a variety of compelling items that made a switch worth an afternoon migration.

Dependency hell

The last thing I want to deal with when I finally get the inspiration to write is a broken build chain. Virtualenv does an okay job of keeping dependencies in line, but at least once a year I had problems that required fixing. I’m not sure exactly what broke since the last time I did the site and now, but with Pelican 4 out I know I’d have quite a bit of work ahead of me getting all of this sorted out. Hugo is a single Go executable, and I’m hoping that will largely be the end of it.

Further to that matter, I’d been maintaining a bunch of plugins which Hugo has built-in. I can’t really speak to extending Hugo, but I’ve gone from 7 plugins to 0, and Hugo Pipes is available if I think of something silly that I need to add (the only thing I can think of is HAML support, but I’ll survive).

Markdown

RestructuredText is certainly a better defined language, but it seemed to me there was little desire to fix its warts. Markdown has a variety of flaws, but with things like CommonMark there’s movement to get it finally nailed down. And if specification were no issue, I think Markdown has a lot more going for it (lots of implementations, for one thing). Now, I know that Pelican has had Markdown support for a while, but once you’ve moved to Markdown, it’s probably time to look at the rest of the field and kick the tires.

Speed

Given the amount of time you spend writing, the build time of the site in theory shouldn’t be a big part of your worries. However, if you’re like me and do a ton of editing before publishing, a 20 second build time is a real pain point. In addition to that, you have to kick off a whole bunch of extra work to see the changes.

This is where Hugo really shines. Hugo is fast, building the complete site in under 100ms. By running hugo server, hugo starts up a preview server that also looks for filesystem events, so every time I change the site, it rebuilds the site instantly, and reloads it in the browser. I didn’t even know I wanted something like that until I experienced it, and now the idea of working without it sounds dreadful. True, I could have set up something like Guard, but the point is that I didn’t have to. It just comes for free.

Pelican to Hugo

There’s no script (that I could find) to move from Pelican to Hugo, but fortunately the process was still fairly painless using generic tools like pandoc and sed. I’ve only done this site so far, but will update this page as I convert my other sites.

Pandoc got me most of the way there conversion-wise, emitting YAML for the frontmatter.

pandoc -s FILENAME.rst -o FILENAME.md

The only real formatting problem I had from that was some plugin-specific stuff (which couldn’t really be helped), and weird escaping on ‘, “, and $ characters.

There are some frontmatter changes you’ll need to make:

Pelican->Hugo
date: 2018-12-1->date: ‘2018-12-01’
tags: a, b->tags: [“a”, “b”]
status: draft->draft: true

I’ve scrapped my old theme for this site and gone with the ananke theme, but I’ve got other sites that I’ll need to convert from Jinja to Hugo’s format. I’ll update this with my findings, but I’m thinking liberal use of search-and-replace will take care of it.

Conclusion

It took me a lot longer than I hoped to move this site over, but the simple act of writing this article has been so painless to the previous system that I’m pretty sure I’ll be writing a lot more now.