[LV123]

"sure enough, doing just that sent me into a rabbit hole of errors"

I did that exact thing in a project last weekend, and ended up spending 5 hours trying to fix the horrible mess that ensued. I only tried doing this in the first place because bundler errored out on installing one of the gems, and I figured a "clean" local setup would fix things.

For some reason the project still wanted to use global gems, and when I tried to delete them to force it to use local gems I broke everything. In the end I just installed RVM with a clean version of Ruby and let it use global gems.

I'm sure I did it wrong, but the errors I got were just insane. I couldn't delete gem X because I had gem Y installed, I couldn't delete gem Y because I DIDN'T have gem Z installed. I couldn't install gem Z to delete Y to delete X because my installed version of gem Q didn't match the version bundler wanted, but I couldn't install a new version of Q because of reasons...

After reinstalling the exact same gems (through RVM instead of the apt-get version of Ruby I had before) things still didn't work, and it took me quite a long time to figure out that the error "your version of [some YAML gem] is wrong" means that you have to add a line of Apache config telling Passenger to use Ruby.

[gls2ro]

I am sorry for your experience with this.

I am just trying to understand your case. So if you have a Gemfile in your folder and then execute something like

     bundle config set --local path "vendor/bundle"

Then all gems should be installed in ./vendor/bundle.

I am not sure how Passenger works (as I am mostly using Puma). I am assuming based on what you wrote that the issue was with the gem passenger itself which is used by the Apache config and it is not a library used by your project.

I don't think the issue you encounter is representative to Ruby and it's ecosystem. I think any module loaded to Apache will probably need a way to know how to load some other modules and probably passenger (via Apache config) needs to know where to find the dependencies it has. Passenger is a web-server so it has its own dependencies.

My suggestion was about the dependencies of your own project.

I am usually doing projects with Rails and Sinatra + Puma + Nginx or Apache and in both of them with the setup I shared I did not encountered any problems releasing the project in production with bare metal configuration (via Capistrano for example) or using Docker.

I am not saying that my experience is representative for everything in Ruby ecosystem. I started using Ruby in 2007 with Ruby 1.8 and I do agree that we had some rough years in the ecosystem specially when working on multiple projects simultaneously.

But now, my experience is a breeze.

On a tangent, I have more problems with npm/yarn than with gems. For example I just started to upgrade an old Rails app to Rails 7 and suddenly on my Mac OS a npm package needs some kind of Python version with some libraries that in turn seems to require some other stuff. Even if I am more like a dinosaurs and prefer to run locally all projects (thank maintainers for asdf) for this one I let it go and put it in docker :)

[LV123]

Thanks, I'll give it another try some day and try switching to local gems. I used the exact command you suggest and it didn't work, but I don't remember why. Unfortunately I didn't keep all the logs, so I don't remember exactly what all the errors were, but I think Passenger was the cause of about half of my woes and I'll look into replacing it.

Bundler was pretty damned useless though, I've had a much worse experience with that than I've ever had with yarn, pip or npm. It really shouldn't be necessary to nuke the whole Ruby installation to do a clean install from a Gemfile, and the errors it produces are extremely misleading and unhelpful.

I'm not really a Ruby dev, I just inherited an ancient Rails project and had to make it work (upgrading from Rails 4 to 7 in the process), so the project setup is less than ideal. I'm sure a lot of my problems were self-inflicted ;-)

[gls2ro]

Thank you for replying to give more context.

You have some courage to go to a Ruby project and try to upgrade Rails from 4 to 7. I hope it will go as smoothly as possible. Props to you!

I am not sure if it helps and maybe you know these, but just in case here are 3 URLs I keep at hand when I upgrade Rails:

1. https://railsdiff.org (where it shows diff from sources)

2. https://www.fastruby.io/blog/tags/upgrades (they have some great articles in cases of some upgrades)

3. https://guides.rubyonrails.org/v6.1/upgrading_ruby_on_rails.... (there is page for each version just replace v6.1 with the major version that you need)

And also if you have not already started may I suggest you don't go directly from Rails 4 to Rails 7 but just try to go to each major(ish) version:

   Rails 4.0 -> 4.1.x
   Rails 4.1 -> 5.0.x
   Rails 5.0 -> 5.1.x
   Rails 5.1 -> 5.2.x
   Rails 5.2 -> 6.0.x
   Rails 6.0 -> 6.1.6.1
   Rails 6.1 -> 7.0.x

For each version there is an upgrade page. Eg:

- https://guides.rubyonrails.org/v4.1/upgrading_ruby_on_rails....

- https://guides.rubyonrails.org/v5.0/upgrading_ruby_on_rails....

- https://guides.rubyonrails.org/v5.1/upgrading_ruby_on_rails....

You might want to give a try to this gem: https://github.com/fastruby/next_rails. I did not used it so far but I would have a Rails 4 app I will probably try to use it.

[LV123]

Thank you! Those resources would have been incredibly helpful 6 months ago, haha.

It was less courage and more desperation, as the project was running on a server which died before Christmas and we needed it back up before January. The last major change to the project was ~6 years ago and nobody had touched it in ~5 years, so there was nobody around who had the slightest idea how it worked. Props to Rails for just working for that long with practically zero maintenance. In case you're wondering why we had critical software running on a single server with no maintenance: student organization.

We weren't able to find/install an Ruby installation old enough to run the project, so we decided to just upgrade. It was the brute force approach of "run the project, see what error pops up, google the error, fix the error, repeat". In hindsight, this wasn't a good idea and I could probably have found the right Ruby version with a bit more digging, but it works at least.

It's just a handful of pages with minimal code though, so now that things are less desperate I'm considering just starting from scratch with a clean Rails install and manually recreating them. Just need to deal with the legacy database schema and make some changes to it.

[revscat]

> I did that exact thing in a project last weekend, and ended up spending 5 hours trying to fix the horrible mess that ensued.

What gem(s) were giving you issues? I can try and replicate it if you’d like.

[LV123]

Thanks, but I don't remember all the details and couldn't replicate it myself if I tried.

The initial "bundle install" failed on "therubyracer" (0.12.3) on Ruby 2.7.4 (installed with apt). As I had previously installed it just fine on the same machine and it now works just fine on Ruby 2.7.4 (installed with RVM), that doesn't make much sense.