SkoolKit 3.3.2 is now available. Should you want a copy – whether in raw form as a tarball or zip archive, or in pre-packaged form as an RPM or DEB file – just head over to the always-welcoming download page and click the appropriate link.
Or, alternatively, you could head over to GitHub and clone the SkoolKit repo. Yes, the SkoolKit git repo is now hosted on GitHub, which means that staying on the cutting edge of SkoolKit development is just a
git pull away. Incidentally, it’s also the place to report bugs and suggest enhancements.
So, besides being the first version of SkoolKit to have been developed ‘in the open’, what’s new in 3.3.2? Well, to begin with,
setup.py now installs the resources directory, which means that a local copy of that directory is no longer required when SkoolKit has been installed via
setup.py install. Whether this counts as a bugfix or an enhancement is probably up for debate.
Also new (since 3.3.1, actually) is the ability to use a standalone extension module that is not part of an installed package. For example, if you’ve implemented an HtmlWriter subclass named GameHtmlWriter in an extension module named game.py that you’d like to keep in ~/.skoolkit, you can make
skool2html.py use it by setting the HtmlWriterClass parameter in the [Config] section of your ref file thus:
If, on the other hand, you are a traditionalist who prefers to keep your extension module inside the skoolkit package itself, then you may find the new
-p option of
skool2html.py useful: it prints the path to the skoolkit package directory. This takes the guesswork out of installing game.py; now it’s as easy as (something like):
$ sudo cp game.py $(skool2html.py -p)
As if all that weren’t enough,
skool2html.py also has a new
-T option that makes switching between CSS themes as easy as pie, and there are a bunch of bugfixes; anyone curious about the finer details can always check the changelog.
And that’s all the news. Git pulling!