PieCrust 0.4.0

The holidays have not just been a time spent with the family eating unhealthy amounts of equally unhealthy food: it was also a time of great changes for PieCrust. So much, actually, that I bumped the version number up twice. This is not just because those changes are pretty significant but also because they break things a bit.

Plugins!

Yes, at last, PieCrust officially supports plugins! The code was already somewhat designed as such, but there was no easy way to write, install and manage plugins before.

Now, it’s pretty simple: each plugin is a bunch of files contained in a directory located in the _content/plugins directory. If you want to share plugins between several websites, you can specify additional directories in which PieCrust will look in a similar way you specify additional template directories: you add it to the site/plugins_dirs configuration setting.

For more information, read the official documentation on plugins.

To celebrate the occasion, I also did some cleanup of the default PieCrust install: the PhamlP features (the Haml template engine and formatter, along with the Sass processor) and the Dwoo template engine have been removed altogether from PieCrust, and moved into their own plugins. Dwoo didn’t add much to the plate that Twig, the default template engine, didn’t have already, and PhamlP is just not working very well (it’s good enough for simple cases, but breaks down if you give it heavier things like the Compass framework files).

Two more plugins have been written:

• The YUICompressor plugin, which is self explanatory.
• The Sass plugin, which uses your installed sass/scss executables to
  convert stylesheets.

The new Chef

Chef, the PieCrust command line executable, has changed. For starters, it now behaves like git or hg, in the sense that it knows if it is being run from a directory within a PieCrust website (it will look for a _content/config.yml file somewhere up in the current hierarchy). This makes it a lot easier to use because there’s barely ever a need to specify the root directory of the website it should act upon. In turn, it streamlines the usage of most commands, making them more natural. However, it means the old parameters and options won’t work anymore – you will get an error instead.

With the new chef also comes a few new commands:

• root: returns the root directory of the website.
• plugins: shows a list of the plugins loaded for the current website.
• stats: shows some stats about the website.
• tags: lists the tags used in the website.
• categories: lists the categories used in the website.

The nice thing about the new chef is that, coupled with the new plugin architecture, it knows about site-specific plugins that could expose new commands. This is very similar to how Mercurial lets you use extensions on a per-repository basis.

That’s about it! I hope you’ll be happy with this major milestone. I’ll merge those changes into the stable branch within a week unless something goes wrong. As always, use the BitBucket or GitHub issue trackers to notify me of the many bugs I likely introduced.