This one's a little vague right now, and I'm not sure how best to test this.
Looking at the mkdocs documentation it isn't clear to me that you *can*
provide the config file to the gh-build command, but there's example command
lines in the docs showing that you can.
Need to see if there's a safe way to test this out -- the last thing I want
to do is nuke our website.
The idea here is that there is a single file for the nav for all the docs,
both online and offline. The nav will be the full online nav in all its blog
glory, and then the build system will strip out the nav items relating to
the blog when building the offline version.
There's a wrinkle or two still in here; the main one being that when doing a
docs-serve, it seems that the cleaning up of the online nav doesn't happen
when you Ctrl-C out of the server. I'm not 100% sure of the cause of
this (there could be a couple of different reasons).
For now... I'm ensuring that the online/offline nav files are excluded from
git. It would be nice to find out how best to always ensure that the online
nav file is removed so nobody attempting to update the docs gets confused
about what to edit.
Makes sense to update all the docs to reflect the work done in #1738 but I
feel it doesn't quite make sense to retrofit this into an old blog post --
especially if the code it is referring to was like that at the time and
likely still will be for a wee while after this gets republished.
The blog files were still getting included and packages, just not linked to
from the resulting "site". This meant that the final tarball was much bigger
than it needed to be, due to animated gifs and movs an the like.
This brings the tarball down from around 27M to 6.4M.
While it's still fresh in my mind as to why I wrote it like this, comment to
the effect so I'm not surprised by it in the future, or so someone else
reading it can know what the thinking was here.
It's a `Makefile` so it's handy to not have to think about if you need to be
within a poetry venv when running `make`. This commit adds a `poetry run`
before any command that needs the venv. This means that people who aren't in
a venv can just `make something` and it'll "just work", and the same is true
for those who are in a venv.
This has the effect of bundling up a bunch of files that would otherwise be
pulled in from the net on the client side. As well as enhancing the viewer's
privacy, it also means that we increase someone's ability to view
documentation locally without the need for any sort of working net
connection.
This removes the duplication of the screen cache cleaning, and also turns it
into a target so you can do it yourself from the command line if needed. It
also marks all the phony targets as such (that is, targets that aren't
actually items in the filesystem).
