So, huge disclaimer, a lesser-known fact (who am I kidding, I'm not ashamed to admit it) is that I'm a bit of aruby newbie.

That is, I've never cared to learnruby before. Also, perhaps as a direct result of that, I am a little taken aback when a project asks me to installruby and use tools that it provides such asbundler , because the assumption there is that I know what I am doing.

Just to set the record straight, I don't know what I am doing when it comes toanythingruby .

Recently, a lot of stuff blew up and hell broke loose, when I inadvertently ranbrew upgrade on my new Mac to update (or upgrade?) packages installed byhomebrew.

But alas, I did not takeruby into account. A while back, I had installedruby with homebrew:

$brewinstallruby

Homebrew, without my permission, apparently took it upon itself to upgrade the bundledruby version - from 3.2.3 to 3.3.0.

Hell broke lose when Icd'd into my project repo that I use formy website, and ranbundle to install fresh dependencies - which was needed, sinceruby version was upgraded, so it was a fresh environment with no gems available.

$bundleinstall

The error I received was something like this:

~/<user>/somewhere$bundleexecjekyll servejekyll 3.9.3 | Error:  undefined method`[]' for nil/usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/logger.rb:384:in `level': undefined method`[]' for nil (NoMethodError)    @level_override[Fiber.current] || @level

This indeed was the specific error message I saw:
Error: undefined method '[]' for nil

Searching online, you can see a whole slew of posts that mention this error, and apparently it only happens with ruby3.3.0 and thejekyll version3.9.3 that comes bundled withgithub-pages .

• https://stackoverflow.com/questions/77851863/bundle-exec-jekyll-serve-not-working-locally

• https://talk.jekyllrb.com/t/unable-to-install-jekyll-on-m3-macbook/8836

• https://talk.jekyllrb.com/t/error-when-executing-bundle-install/8822

Hence, while it might not bear repeating, it helps to clarify - upgradingjeykll version for a project is ano-go, especially when the projectGemfile relies explicitly ongithub-pages dependency, whichitself relies onjekyll :

gem"github-pages",group::jekyll_plugins

And yes, just to double check, theGemfile.lock should show the lines that clearly show the dependency relationship between the

github-pages(228)github-pages-health-check(=1.17.9)jekyll(=3.9.3)...

To recap, if one installsruby withbrew and runsbrew upgrade or similar and results inruby@3.3.0 being inadvertently installed, this can break when attempting to work with projects that rely on a specific version ofjekyll, especially ones that rely ongithub-pages gem for deployment.

There does not appear to be any solution involvingbrew andruby alone.

Upon catching the issue that the mismatch b/w the two gems caused the build error when runningbundle exec jekyll serve , I immediately tried some steps, that first involved installingcsv , as apparently there was a warning printed to terminal since that doesn't come bundled in ruby 3.3.0

$bundleinstallcsv

Then I tried to upgrade allgem versions in project by running:

$bundleupgrade

That didn't help, so I tried to specify both gems explicitly:

$bundleupdatejekyll$bundleupdategithub-pages

Still no dice, and I was at wit's end by now. Manually upgrading either of thosegem versions specified inGemfile.lock didn't help either. There was a dependency conflict if I upgradedjekyll, asgithub-pages relied on a specific version.

I also tried deletingGemfile.lock file completely and runningbundle again, but still no dice.

In short, this was exactly what they call "dependency hell". I cannot change either gem versions, and hence this is basically a "SNAFU!" situation. As in, there's no solution to be had that allows me to keep the up-to-dateruby version 3.3.0 for use with my project.

I even tried uninstalling and re-installing specific ruby version 2.3.2 viahomebrew, but if you can believe it therestill was no dice:

$brew uninstall ruby$brewinstallruby@3.2$echo'export PATH="/opt/homebrew/opt/ruby@3.2/bin:$PATH"'>> ~/.zshrc$source ~/.zshrc$ruby-vruby 3.2.3$geminstallbundler$bundle<error>

I'll be honest, I felt like tearing my hair out at this point. Sweat started metaphorically trickling down my back. Being aruby newb, I was about to throw in the towel, and as a last resort maybe open up an issue on the project page for one of the gems, or post about it on a forum asking other users for help.

Now that I think about it, maybe ChatGPT could have helped me. Hello ChatGPT? Can you explain this error please, and suggest me a solution <paste stack trace>.

However, thankfully, that was ultimately not needed. I found a workaround that helps me to maintainruby version across different machines, consistently.

After researching online for quite a bit, I found out that someone was usingrbenv and decided to look into what that is. Turns out, it's something similar likepyenv forpython, or basically a version management tool for a programming language.

Feeling I was on to something at this point, and shrugging my shoulders after realizing I had nothing to lose, I decided to install it after all:

$brewinstallrbenv ruby-build$echo'eval "$(rbenv init - zsh)"'>> ~/.zshrc$source ~/.zshrc

That got me therbenv command, but of course I wasn't done there yet.

I have to install my necessary previousruby version3.2.3 withrbenv :

$rbenvinstall3.2.3

After installing a version withrbenv , you can set it eitherglobally (so thatruby version is changed regardless of your location in terminal) orlocally, so it will only affect a project after youcd into its folder.

I decided to doboth, because the defaultruby version that comes bundled with my new Mac Air M2 laptop is something like2.x , which is hella old. And I'm clearly never gonna use the built-in one.

$rbenv global 3.2.3$rbenvlocal3.2.3

Now we're cooking! To double-check that we got the newruby version installed:

$ruby-vruby3.2.3(2024-01-18revision52bb2ac0a6)[arm64-darwin23]

Great! Now that's out of the way, we want to install or upgradebundler, and then we're good to go.

$geminstallbundler$bundle-vBundlerversion2.5.5

If it helps, one might need to delete and re-createGemfile.lock by runningbundle, especially if it says the gems were installed with another version ofbundler :

BUNDLEDWITH2.5.4

After that, you can runbundle exec or however you start up your project that relies onjekyll andgithub-pages , and then you should be all set.

If it helps, I've actually created an alias commandjb , which serves that exact purpose in my case:

$which jbjb: aliased to bundleexecjekyll serve-low

It's easy enough to add that alias in tobash orzsh shell configuration. To add it tozsh - my default interpreter - here's what I did:

echo"alias jb='bundle exec jekyll serve -low'">> ~/.zshenv

Thensource ~/.zshenv to reload the changes in the current terminal window.

All said, this whole ordeal took me>1 hour of pointless debuggery. It was the exact opposite of fun. And, ideally not how I would have wanted to spend a Sunday morning.

However, the upshot is that the confusingruby versioning hell along with two of the aforementioned gems -jekyll andgithub-pages - is now finally resolved, at long lost.

Here then was a lesson learned: manageruby versions withrbenv instead ofhomebrew.

Praise be! Massive dependency hell solved, and headache (mostly) avoided. Hope this helps someone else out. Now go out there and get coding!

Originally published athttps://ritviknag.com on January 28, 2024.