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.
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).
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.
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
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:
|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.
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.