Following my fun with V0.152.0 - Error: command error: failed to load modules and noting that I was having the same problem as Sam blogged ( Installing Old Versions with Homebrew | The Blog of Sam Craven ) it had me wondering if there was a way to improve the Homebrew install (and specifically the revert) functionality.
Unfortunately I’m not at all familiar with Ruby, and looking at homebrew-core/Formula/h/hugo.rb at main · Homebrew/homebrew-core · GitHub I couldn’t see any obvious clues as to who and how this process is maintained. I know there’s a very handy status update that @martignoni provides on each release posting, but I wasn’t assuming that that means they were responsible for the external builds…?
Also not sure which development tribe this fits into - Hugo’s or Homebrew’s, so starting here 
I’m wondering what might be involved in having a scenario where the Homebrew fixed builds for Hugo are available for the latest, and the past 2-3 minor releases. I.e. since Hugo’s still on v0 for major releasing, the homebrew options would be default to latest (as current), and then a hugo@0.151.2, hugo@0.150.1, & hugo@0.149.0 - where the previous versions would favour the latest patch release in that minor number sequence.
This looks like it involves maintaining a series of Ruby formulas, but I’m imagining there’s a build process somewhere that generates these formulas? And if so, could we (I’ll offer what little help I can ) extend that process please?
Would make like a lot more straightforward for our macOS/linux homebrew users to handle local development hiccups that can occur whilst still allowing us to easily download the latest version of Hugo to test and move forward.
1 Like
I like this idea as well, but I perhaps see why this hasn’t been done.
Brew’s design seems to favor single formula / single version.
Different versions of a tool require unique formulas, it seems. So postgres@17 and postgres@18 are distinct formula from each other, not versioned subsets of a master postgres formula.
With major/minor/patch release numbering methods, there seems to be a general norm that formulas for each major release are done, but not for minor/patch. Python is an exception to this, and shows that minor-number based formula can happen, in this case based on Python’s longevity of 3.x and the minors being a concern for compatibility I guess.
Since Hugo seems to follow the infinite zero release numbering, it might be more difficult to maintain the changes for Brew. I don’t know how easy it is to add and delete versioned formula, so maybe this is part of the reasons why this wouldn’t be desirable?
The YAML library fixes in 0.152 are a good example of how Hugo’s versioning might make reasoning how many versions to maintain might be difficult. Do we want to maintain just a fixed number of previous versions? Or a fixed number of potentially breaking change releases? Not sure what would work best.
I know in my own CICD, I’ve had to pin the version of Hugo and occasionally test latest version and increase it only after testing. One could argue this is best practice, and I tend to agree. But when a breaking change happens, like it did with 0.152, it would be nice to be able to revert our test/local systems using Brew.
The short-term issue (“failed to load modules”) was resolved with v0.152.2.
Regarding brew downgrades, I’ve written about this before:
https://discourse.gohugo.io/t/how-to-downgrade-hugo-to-a-previous-version/40388/5
Yuck.
1 Like
Fantastic and quick work - my thanks to your collective efforts on the fix.
Now to (ironically?) await the Homebrew update to test out the results
I’m not surprised this topic has come up before - I’m slightly disappointed in myself that I didn’t find that thread earlier - it seems to be an awkward problem to fix but a lightly desirable one.
When it comes to our CI processes - yup, our containers have pinned versions of all the dependencies to avoid this problem. This is more the case that local machine is typically our starting development/testing location and thus has a tendency to be on the latest versions of xyz as quickly as possible so that we can try before we nudge the CI pipelines along.
Thankfully this doesn’t tend to be an issue for 90% of the time - and in reality, the very short wait for a fix to be found has meant the impact on getting stuff done has been virtually zero, so I can sweep this under the rug for another occasion
Looking at the hurdles though - I’m not seeing an obvious pathway or blocker that needs to change for this to be solvable within the two ecosystem’s ways of working. C’est la vie then