๐พ Archived View for agnos.is โบ projects โบ gempost-rework captured on 2024-12-17 at 09:38:22. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Gempost is what powers this capsule.
I am forking and reworking it.
It seems like gempost is pretty much abandoned, especially because JustLark's Gemini capsule is now offline. I am taking Gempost in a new direction, unifying the features of pages and posts together. This will simplify my own site configuration, and I think make the tool more useful to people who want a more generalized static site generation solution for Gemini capsules.
Eventually, this page will serve as full documentation of how to use the new (and likely renamed) gempost.
These are features I've already added.
The `base.tera` template is a common template that all pages use as a layout, unless overridden by the new `layout` option in the sidecar YAML file. A layout Tera template has the following available to it:
All pages (NOT posts! yet.) are themselves templatable, similar to how Jekyll handles HTML or Markdown content. They are handled as full Tera templates, which means all Tera features will work with them, including extends and includes.
The following variables are available to pages:
There is a new `layout` option available in the sidecar YAML for pages. It is the layout template to use. By default, if it's not specified, this will be "base", which means it will read the `base.tera` file from the pages template directory specified in the gempost config file.
I have also updated the error reporting during templating for pages. The application will now output exactly why a templating operation failed, rather than just the top-level (and usually unhelpful) error.
There is still much to do, to get Gempost to the state where I want it. Things I'm thinking about:
The original motivation behind adding fully templatable pages to Gempost was so that I could have my sections menu be dynamically inserted in both the homepage and the section page itself. Because Tera supports pulling values from environment variables, I have a very janky way of creating the dynamic sections list.
The template looks like this:
{{- get_env(name="SECTIONS") -}}
Then my `Justfile` uses an abomination of the find command and a `yq` query (`jq` but for YAML) to generate the menu:
yq_query := '{ "file": "{}", "name": "\(.values.emoji) \(.title)" } | { name, "link": (.file | ltrimstr("' + pages_dir + '") | rtrimstr("index.yaml")) } | "=> \(.link) \(.name)"'
This works but is not sustainable or user-friendly, even for Gemini tech nerds. I want to replace it with something more structured, obvious, and extensible. Tera supports adding arbitrary Rust functions to the templating engine, so I will be cooking up some Rust code to handle structured data, either supplied from static JSON, or somehow dynamically generated.
This is a pretty obvious feature, and easy to do. Adding a `values` section or something to the gempost config file would allow the site to read this data on any page during site compilation. Useful for stuff like content license (already in gempost), author, dates, contact information, etc.
Most of the work I've been doing is on the pages feature that I added earlier in 2024. The original posts functionality of gempost can obviously benefit from these new features.
โโโโโโโโโโโโโโโโโโโโ