If you switched to Python, then you probably traded your `bundle install` errors for `pip install` errors ;-)

Pip doesn't do dependency resolution either... I spent a day trying to pin down issues migrating a project from pipenv to poetry because poetry did not agree with pipenvs resolution.

AFAIK, pip does dependency resolution, you can disable it via --no-deps

https://pip.pypa.io/en/stable/topics/dependency-resolution/

Excuse me I should have said conflict resolution.

For what it's worth that's also been my experience with some Ruby projects I have. Usually bum-simple Jekyll web sites in response to a dependabot warning.

It's almost always a fight to get going again and it seems so needless. Like just reinstall the gems from scratch if you need to, jeez, this isn't even a CI I don't need the gems to be literally identical to what was here a year ago, I just need "bundle exec jekyll serve" to actually do something...

That all said I still like Ruby as a language, it brings the good stuff over from Perl while being as expressive as Python and pretty damn fast to boot. And I recognize Python also has similar dependency challenges. But this is very irritating.

> It's almost always a fight to get going again and it seems so needless

Hm. I do ruby webdev stuff for over a decade now (first ramaze, hanami now) and use a self baked overlay that manages multiple hanami apps and capistrano to deploy them and shares plugins to all the webapps (like a blog component).

I love it. Sure, there were problems with bundler and some with capistrano too but overall its very pleasant for me.

I am sure it will not bring you back :) but in case others might read this and have the same issue the solution is to config bundler to install the gems locally inside a project folder (I usually go for ./vendor/bundle) and the add that to .gitignore

This way if you work with multiple projects each using different Ruby versions and different gem versions you don't keep to keep reinstall the gems whenever you switch the directory.

"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.

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 :)

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 ;-)

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.

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.

> 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.

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.

Gems are versioned already, and if you're working with different Ruby versions, your gems are already isolated to that version.

No need to vendor gems.. Vendoring millions and millions of duplicate files is for the node crowd.

> Vendoring millions and millions of duplicate files is for the node crowd.

and PHP

Gems are versioned already, and if you're working with different Ruby versions, your gems are already isolated to that version.

No need to vendor gems..

as an other perspective this happens because you are not pinning the versions correctly. your gemfile should have an explicit version of every major gem you use and the gemfile.lock should have the resolved dependencies already made out and committed. you should also have a particular version of ruby in mind and locked with a .ruby-version file in the project root. This should work flawless in all but the oddest edge cases.

Leave a javascript project for more than 2 weeks and you'll get the same thing.