Why is rails 7.2 requiring all these gems?

rubyonrails-talk
1

Trying to install Rails 7.2.2.1 (my options are limited at the moment… can’t use Rails 8)

Something is requiring gems that I never “ordered” (I don’t have them in my Gemfile). Server won’t start, giving this error message:

Could not find sprockets-rails-3.5.2, bootsnap-1.18.4, brakeman-7.0.0, web-console-4.2.1, capybara-3.40.0, selenium-webdriver-4.28.0, sprockets-4.2.1, nio4r-2.7.4, msgpack-1.8.0, regexp_parser-2.10.0, irb-1.15.1, bindex-0.8.1, addressable-2.8.7, mini_mime-1.1.5, nokogiri-1.18.2-x86_64-linux-gnu, rack-3.1.10, rack-test-2.2.0, xpath-3.2.0, logger-1.6.6, rexml-3.4.1, rubyzip-2.4.1, websocket-1.2.11, websocket-driver-0.7.7, rack-session-2.1.0, rails-html-sanitizer-1.6.2, useragent-0.16.11, builder-3.3.0, erubi-1.13.1, bigdecimal-3.1.9, concurrent-ruby-1.3.5, connection_pool-2.5.0, i18n-1.14.7, rackup-2.2.1, rdoc-6.12.0, public_suffix-6.0.1, net-imap-0.5.6, net-smtp-0.5.1, loofah-2.24.0, psych-5.2.3, crass-1.0.6, stringio-3.1.3 in locally installed gems

Is there something other than the Gemfile that causes this? For example – I am pretty sure one can use nokogiri-1.16 with Rails 7.2. Where is this demand for “nokogiri-1.18.2-x86_64-linux-gnu” coming from ??

It is conceivable this is happening to me due to third-party containerization, but I am inclined to believe it is not (though not 100% certain) … checking with this forum to rule that out, definitively, or in.

Is anyone familiar with these weird gem requirements? This is a new install…

2

Each gem can have dependencies upon other existing gems – and overall Rails makes good use of this. So these additional gems are part of the whole lineup.

If you execute just bundle from the root folder of your project then it will try to do something called a “bundle install” – which should retrieve all of these. Afterwards you’ll see the retrieved versions noted in the auto-generated file Gemfile.lock.

Some (like nio4r and nokogiri) have portions called “native extensions” which are compiled form C code. If you run into any trouble during the bundle then these could be likely culprits – and we can sort this.

Altogether this is expected behaviour, and welcome to development with Rails!

3

I can’t use “bundler” … AT ALL… company forces a wrapper to track installs. Since posting above I am beginning to think the external version/dependency tracker is somehow penetrating into the Rails layer and forcing this. But even that does not explain it, since we are observing inconsistencies across installs (some similar installs do not manifest this error, and allow one to not state the gems explicitly in Gemfile).

If this forum confirms that logically such behavior is not observed in normal installs, we will dig deeper into the said third-party wrapper/container behavior

4

Remarkably there’s a word for trying to use Ruby without bundler – we call that “heresy” :crazy_face: hehe!!!

jk – but it will be a significantly rougher ride without bundler – and certainly far less convenient. I can’t think of any real benefits for deferring this critical part of Ruby. (After all, it’s installed along with the language itself!)

There is an unsupported alternative called gel, but really, anyone doing Ruby development should want to make use of bundler.

In ultra-secure environments you can set up your own gem repository so that you’re not using https://rubygems.org, so if that’s the main concern then perhaps you can get past that hurdle.

With other programming languages there are sometimes multiple popular package managers (For instance with Javascript there’s npm, yarn, and pnpm.). Here in the Ruby world we stick with bundler.

5

Thanks for reflecting on that. I will be opportunistic and follow up with pain sharing… What you say resounds with common sense and sensibility on all levels! Including - why not leverage a great product (bundler) into which thousands of diligent, smart people have invested their talent! And yet… it so pleases certain (unnamed here) company to scrap it to the curb and impose its own component installer/tracker (this tracker is all-encompassing, tracks versions and dependencies of ALL software components – Ruby, Java, Node, and everything else)… that code jumps through hoops to accommodate but, as one can imagine, adds IMMENSE complexity… and with extra complexity come extra bugs, and lots and lots of PAIN, and time drain. What one can do in the normal world may take 10x more effort, with this “accommodation”

(Heads-up to other Rails devs – you just might run into a company/employer that does this. Also, enjoy and appreciate the free world !!! )

6

What you describe is some sterile space worse than raw entropy itself – a place in which things reach homeostasis only when below-average. I believe I’ve occasionally seen this kind of thing in action in some organizations – and left unchecked it can become heinous. End game here can be as bad as a dystopian realm where everything ends up in this sub-optimal state. Existing checks and balances that were sufficient are doubted and then become encumbered by additional layers of new checks and balances, creating a series which can become a litany. Any hope to easily create something real is nigh impossible as it must exist with many crusty barnacles attached. It resembles a person in urgent end-of-life care in an ICU ward – IV bags and monitors of all description that completely interfere with the ability for that individual to act.

This is not Rails. Instead, the Rails ecosystem works wonderfully in any environment where there is true freedom. It was designed from the start to thrive in that kind of space.

I recommend putting together all forms of documentation which represent your own personal self – your identity in some fashion – and keep that stuff close. Then with that treasured, find a way to escape into a space where more freedom is available.

All the best in order to reach a more blissful realm!

7

Thanks for the amazing and apt metaphor! I think you nailed it. If a company is of behemoth size, popular, with enormous-size clientele and profits it can afford to dictate in this manner. The system is deemed viable – because profits continue to be churned out, and there is a critical mass of devs who have bought into the sport(?)/challenge of coping with and navigating past the misery, and do not complain - they get their paychecks. My abstract take on it … the binary choice for devs is: either embrace it full-force or leave; no in-between. So, you don’t hear outcries about how suffocating it is… I think the underlying, tacit consensus is that the pain is par for the course, and they have to endure it. Perhaps they understand the big-picture trade-offs and believe the trade-offs are unavoidable, and perhaps even believe they are necessary for the company’s survival. That without the overarching control mechanism software development would degrade into entropy that will break the business. Which, of course, is paradoxical and ironic, next to your point, and your point is completely valid and true. And probably there was another way to set things up during the company’s nascence in late 90’s, but this is how the cookie crumbled back then.

With respect to the full freedom you speak of: I think about it longingly every now and then. And your advice to pursue it is sound.

1 Like