sushy

Ha. Well, https://taoofmac.com was ported to Hy (https://github.com/rcarmo/sushy) in a week, then I eventually rewrote that in plain Python to do the current static site generator —- so I completely get it. I am now slowly rebuilding it in TypeScript/Bun and still finding a lot of LISP-isms, so it’s been a fun exercise and a reminder that we still don’t have a nice, fast, batteries-included LISP able to do HTML/XML transforms neatly (I tried Fennel, Julia, etc., and even added Markdown support to Joker over the years, but none of them felt quite right, and Babashka carries too much baggage). If anyone knows about a good lightweight LISP/Scheme dialect that has baked in SQLite and HTML parsing support, can compile to native code and isn’t on https://taoofmac.com/space/dev/lisp, I’d love to know.

Mine’s in Python. I took that route when it was a relatively obscure thing and PHP was gaining ground over CGI in Apache (at the time having a Python web server was downright weird) and stuck with it for a long time. These days it’s a purely static site generator and a bit too funky to release (there’s a variant over on https://github.com/rcarmo/sushy) but I really enjoyed maintaining it while it was a small, batteries included environment. I considered switching to Lua (actually Fennel) but luarocks can be fiddly to use across platforms (I now run everything on ARM servers) and that pretty much was the end of that. So I’m curious as to how maintainable a Lua back-end is over time.

At long last! Now I can finally clean up https://github.com/rcarmo/sushy (I've been poking at it over the years, but every time I upgraded hy portions of the syntax broke, or things would get moved in and out of the hyrule package, etc.) By the way, Hy works really well inside https://holzschu.github.io/a-Shell_iOS on the iPad, although the syntax highlighting in vim/neovim needs to catch up to the 0.29+ releases and async. Although I've tried using Fennel and Guile instead over the years, having access to Python libraries and ecosystem is preferable to me, and with async I can do some very nice, efficient API wrangling (doing HTTPS with fine-grained control over socket re-use and headers remains a pain in various Schemes, so I very much prefer using aiohttp)

Well, I built my static website generator out of Bottle - a single-file HTTP framework that has built-in templating. Bolting on a route that renders Markdown files is pretty simple, really, and a simple os.path.walk() and directly calling the routed function will let you do everything you need. So you only really need bottle and markdown in your requirements.txt, and around 100ish lines of code. Maybe a little more if you want to upload the results to Cloudflare directly (for which I’d use requests). You can rinse and repeat that with aiohttp and markdown if you want the async flavor (which is what I’d do these days if I hadn’t already “finished” mine). And, if you’re into LISP… https://github.com/rcarmo/sushy might make for some fun reading.

Very nice. Like my own stuff, you have an index file and dependent media per folder, which is the only real way to scale out beyond a few dozen pages (my site has… a few more - https://taoofmac.com/static/graph) One suggestion I’d make is to do two passes—one to index all the inter-page links, another to actually render the templates. I do that (and full text search) with SQLite: https://github.com/rcarmo/sushy/blob/master/sushy/models.py

I had to build mine: https://github.com/rcarmo/sushy

My test cases are at https://github.com/rcarmo/sushy/tree/master/pages

I am using roughly 200 lines of Fennel to do that, and my current website (taoofmac.com) is nothing more than 17+ years of that exact approach, but using Python. If you’re looking for inspiration, the older source code is up at https://github.com/rcarmo/sushy. The current version is pure Python 3, but I haven’t cleaned it up for public use (and likely never will, since I want to do something simpler now).

There are four things I quite enjoyed creating, in no particular order: - https://github.com/rcarmo/pngcanvas because there was nothing similar that ran on Google App Engine - https://github.com/rcarmo/imapbackup because I needed a migration tool from Sun IMS to Exchange - https://github.com/rcarmo/rss2imap because it helped me survive well beyond Google Reader for a long time - https://github.com/piku/piku because it enabled me to automate away 99% of my non-Docker deployments and is a lot more fun than Kubernetes on low-end standalone boxes There’s also my blog engine (https://github.com/rcarmo/sushy), but that is in a state of flux right now and I haven’t published the new source yet.

This is hilarious because I’m currently converting my own blog engine (https://github.com/rcarmo/sushy, which powers https://taoofmac.com) to a static site generator, and have decided to port it to Rust sometime in the future.

I ended up dropping Hy very soon after they dropped let. Had an entire blog engine written in it: https://github.com/rcarmo/sushy ...but I wanted Hy to be LISP, not a thin veneer over Python.

I wrote https://github.com/rcarmo/sushy on it before they moved let to contrib. (I later ported it back to pure Python 3, because I couldn’t move forward while Hy was in flux) If let was “fixed”, I’d probably move back to Hy.

Yeah, that was one of the main reasons I stopped using it. They’re doing async now (which was another), but having let as a contrib macro and not in core still puts me off a bit. I wrote my entire blog engine on it - https://github.com/rcarmo/sushy/tree/master/sushy - and then ported it back to Python 3