> I was really impressed with how you've made your own book-building script [0], which I assume you found comfortable iterate off of from your previous book [1].

Yup, though I ended up significantly expanding it over time. This book is a lot more complex because the snippets interact across chapters. Also, I wanted the ability to test the code as it exists at different points in the book.

> but did you ever look into other bookmaking frameworks

Briefly, yes. But, in general, I'm not much of a "framework" person. I'd rather spend time rolling my own thing than reading docs or fighting with the limitations of some other framework.

Of course, doing it from scratch can be a large undertaking, but I think people often overestimate the effort of writing bespoke software. The build script for my book is not a general-purpose build system for generating book sites. It is literally hard-coded to be used for only one single book on Earth.

That makes it much simpler. It doesn't need extensibility or configurability. It has nothing like an "API" or even docs or tests. The output is its tests — if I like the resulting HTML, the build script is by definition working correctly.

It's also easy to add hacks in there that only make sense for the book, like:

    # The "(?!-)" is a hack. scanning.md has an inline code sample containing a
    # "--" operator. We don't want that to get matched, so fail the match if the
    # character after the "-- " is "-", which is the next character in the code
    # sample.
    EM_DASH_PATTERN = re.compile(r'\s+--\s(?!-)')

If I was trying to make a general purpose book-building framework, I'd have to design some elegant or extensible solution for escaping or recognizing false positives in the code that converts `--` to em dashes. But because this is just a bespoke script, I can just toss a hack in and be done with it.