Skip to content

Updating to Hugo 0.156.0 and later: site.Author broken, what to do with Atom feeds, and so on #714

Description

@agriyakhetarpal

As part of the discussion in #692, we stumbled into a problem that will arise when updating to Hugo 0.156.0 or later versions released to date, with the latest version at the time of writing being 0.164.0.

Currently, we use https://github.com/kaushalmodi/hugo-atom-feed as a theme for our theme, to add Atom feed functionality. It has been unmaintained for years, as unfortunate as that situation is. Hugo 0.124.0 deprecated the site.Author field, and it was fully removed with Hugo 0.156.0. Currently, there is an open PR to fix this: kaushalmodi/hugo-atom-feed#22, but it is unclear to us when it will be merged (if ever).

There are some issues with all approaches through which we can think of tackling the situation:

  • Vendoring https://github.com/kaushalmodi/hugo-atom-feed: the code there has always been GPL-licensed. Vendoring layouts/_default/list.atom.xml, as I was unknowingly trying in my earlier iterations of Add partial decorators for better composability #692, would mean we can no longer use the BSD license, which we do not want.

  • Drop the submodule and think about reintroducing Atom feeds on another day, and only rely on Hugo's built-in RSS for now: this would work well, but we don't have a sense of how many people use them on the current sites using the theme, I reckon. It would be nice to find out if this breaks any of our users. As far as I was able to find, only https://blog.scientific-python.org enables Atom feeds.

  • On the possibility of migrating to the two alternative Atom feed options I posted in Add partial decorators for better composability #692 (comment):

    • https://github.com/yelosan/hugo-feeds cannot be used, because it has its own licensing mess. There is GPL code in the repo by Kaushal Modi and other authors from 2018 to 2020, during which list.atom.xml was developed on. The license was swapped from GPL to MIT in 2022 during their Codeberg migration 🤦🏻 We should not rely on it without clarification from its maintainers.
    • https://github.com/hugo-fixit/hugo-atom-feed is fine, but it was not designed for our theme; rather, it was designed for the FixIt theme. We'll need to fork it and fix the layout (which is a bit of work, and I am unsure if we want to go that far to fix the Atom feed). It covers roughly half of what we need.
  • We can write our own template against RFC 4287, and use that as a clean room implementation of a permissively licensed Atom feed syndicator for Hugo themes (or at least our theme needs, at the very least. This can be minimal on purpose and does not need to depend on the semantics of https://github.com/kaushalmodi/hugo-atom-feed, which includes many details we have not needed. I know about the Atom format, but I have to admit I do not know enough about it yet to write my own feed integrator. Note that this is something we'll need to do entirely on our own, as opposed to using any sort of AI coding agent assistance, even minimal. This is because AI systems have likely embedded https://github.com/kaushalmodi/hugo-atom-feed in their training data, which would mean we would quickly run into copyright concerns regarding the fidelity of an implementation and clean-room-ness.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions