Ruby 3 overcommit & psych issue - ruby-on-rails

I am upgrading a Rails project to Ruby 3.1.2, from 2.6.6. I initially ran into this problem, but fixed it with adding gem 'psych', '< 4' into the Gemfile. I should note that an answer there mentioned downgrading to Ruby 3.0.3, but that does not fix my issue.
After adding that, the project worked fine regarding Psych. Unfortunately, when trying to commit/push, the overcommit hook returns this error:
/.rbenv/versions/3.1.2/lib/ruby/3.1.0/bundler/runtime.rb:309:in 'check_for_activated_spec!': You have already activated psych 4.0.4, but your Gemfile requires psych 3.3.2. Prepending 'bundle exec' to your command may solve this. (Gem::LoadError)
I also tried changing overcommit's version and got this error:
Since "psych" is a default gem, you can either remove your dependency on it or try updating to a newer version of bundler that supports psych as a default gem.
Is there any way to fix this, or a specific overcommit version that would bypass this error?

Came across similar issue. So, posting here in case it may help somebody.
With Ruby 3, you need to add psych ~>3.0 to the Gemfile explicitly, because the default version of psych which comes bundled with Ruby 3 starts giving errors as it doesn't quite understand how to handle aliases.
If you still wish to use default psych which comes bundled in with Ruby 3. You can load your YAML files like:
YAML.load_file(file_path, aliases: true).
In my case, I had dependencies loading YAML files so I decided to downgrade the psych version instead of loading YAML file with aliases: true.

Related

Ruby on Rails legacy application update generates Gem Psych Alias error Psych::BadAlias

Goal: Upgrade legacy app step by step as recommended by the RailsGuides: Upgrading Ruby on Rails (from ruby 2.3.1 and rails 4.2.2)
Expected result: rake assets:precompile completes successfully without a gem psych alias error: Psych::BadAlias
Help needed: Can someone please tell me how to implement the recommended solution: Psych::AliasesNotEnabled: Alias parsing was not enabled. To enable it, pass `aliases: true` to `Psych::load` or `Psych::safe_load` . What is (a) the code and (b) which file does it belong in. Full details follow.
Actual result:
I am updating an application from ruby 2.3.1 and rails 4.2.2: I stepped through major ruby revisions, i.e., 2.4, 2.5, 2.6, and am currently running 2.7.0 I updated rails to ~> 5.0 and then issues with the psych gem arose:
Problem: Running: rake assets:precompile led to: rake aborted! / Psych::BadAlias: Cannot load database configuration / Unknown alias: default / Caused by: Psych::BadAlias: Unknown alias: default / error: Precompiling assets failed
The recommended solution is: Psych::AliasesNotEnabled: Alias parsing was not enabled. To enable it, pass `aliases: true` to `Psych::load` or `Psych::safe_load`
I learned that psych 3.1.0 is a "default gem" (when I tried to delete / reinstall psych since it wasn't in my Gemfile or Gemfile.lock). So, I added gem 'psych', '~> 5.0', '>= 5.0.1' to the Gemfile and installed it, ran bundle install, and then ```rake assets:precompile`` -- which returned the same psych aliases error.
Unfortunately, I don't know how to pass `aliases: true` to `Psych::load` or `Psych::safe_load`
The accepted answer to this SO Q&A was helpful: visit_Psych_Nodes_Alias: Unknown alias: default (Psych::BadAlias)
Adding the recommended module YAML as lib/yaml.rb (the right place?) didn't resolve the issue.
I did more research and discovered a Rails patch: https://discuss.rubyonrails.org/t/cve-2022-32224-possible-rce-escalation-bug-with-serialized-columns-in-active-record/81017 which noted that rails 5.2.8.1 (among others was "fixed"). So I upgraded to rails 5.2.8.1 and the error persisted.
Then, since the SO Q&A cited above ended with a "Note for Rails users (>= 7.0.3.1)" and the rails patch said rails 7.0.3.1 was a "fixed version", I upgraded to rails 7.0.3.1 and added the recommended code - from the Note - to resolve the psych issue:
# config/initializers/activerecord_yaml.rb
ActiveRecord.use_yaml_unsafe_load = true
It didn't work. rails app:update recommended numerous changes and, when running rake assets:precompile, I get an unrelated sprockets / popper.js error (probably higher in the stack than the psych error). So, I downgraded the app to rails 5.2.8.1 (with ruby 2.7.0) and am again getting the psych alias error when running rake assets:precompile
Hopefully, resolution is as simple as someone telling me how to implement the recommended solution: Psych::AliasesNotEnabled: Alias parsing was not enabled. To enable it, pass `aliases: true` to `Psych::load` or `Psych::safe_load` .
Also, what's a reasonable approach for the step-by-step upgrade of my code. I.e., once this issue is resolved for rails 5.2.8.1 should I skip ahead to the next fixed version (6.0.5.1)? The SO Q&A suggests different versions of psych for different versions of ruby; the issues are also related to different versions of rails.
Thank you in advance for your help. (I've returned to coding after a 3+ year break.)
use a psych version below 4 and it should work again. It's because of a breaking change in PSYCH:load in v4. If you want to use a newer version, aliases: true would be necessary... am also upgrading old rails apps. it started breaking on upgrade rails 5.0 to 5.1
I popped this error when running rails db:seed after updating a legacy Rails app.
Fixed this error by removing gem versions in my gem file and running bundle update
My Faker gem was set to ~> 2.7.0 and wasn't updating with the rest of my app.
It should tell you which gem is causing the YAML parsing error. It's most likely not the PSYCH gem.

rails uninitialized constant Sprockets::SassCacheStore

I'm new to rails and trying to do some playing around with gems and such.
My case here is that I have this navigation menu on my website and I needed to get the current_page link selected.. rather than building a helper I wanted to install a gem so I went and looked for one and found this one.
I then followed what the documentation said:
In my gemfile I added
gem 'rack_current_page'
Then in the project root config.ru
require ::File.expand_path('../config/environment', __FILE__)
use Rack::CurrentPage
run Rails.application
And finally I ran:
bundle and rails s only to find out I had this error:
uninitialized constant Sprockets::SassCacheStore
The error happens when including the application stylesheet in the layout file.
I'm using the following packages / versions (only listing what might have impact - if I'm missing something let me know)
(<gem> -v)
Rails 4.2.1
Sprockets 3.0.0
Sass 3.4.13
Rack 1.5
While doing the uninstall I removed every line I added - heck I also reset my project files to head since I just started working on it anyways,
ran a fresh bundle, restarted the server, checked the site but all I'm getting is the error above..
I googled and tried to look for a similar question on SO but couldn't find any so the only thing I could really try was the uninstall and reset my git.
I'm definitely looking over something really stupid but can't really find the answer so here I am ;)
Any help is appriciated, thanks in advance and comment if I missed info that you guys need.
time of writing
I actually did a quick gem pristine --all with no results either.
EDIT 1
Okay, so with abit of guesswork and the same situation happening before resulting in the recreation of a fresh app in the (short) past I uninstalled the compass-rails gem and ran bundle afterwhich rails s to test if things started working.
It did. Then I went on and reinstalled compass-rails and it kept working... getting quite confused now :S
Okay so here goes:
I've found the problem and it was solved by actually supplying a version that works with rails 4.2.
The default gem compass-rails installs a version incompatible with sprockets.
When I added the specific version as seen here and ran another bundle the versions of most of the packages I named in the question changed.
console output after gemfile modification included:
Installing sprockets 2.12.3 (was 3.0.0)
Using sprockets-rails 2.3.1 (was 2.2.4)
Installing sass-rails 5.0.1 (was 5.0.3)
Installing compass-rails 2.0.4 (was 2.0.1)
Guess it's just waiting for compass to release a compatible version.

How do I avoid the circular argument reference warning in activesupport

How do I avoid the circular argument reference warning in activesupport. Happens on ruby 2.2.0
/home/ec2-user/apps/foo_prod/shared/bundle/ruby/2.2.0/gems/activesupport-3.2.21/lib/active_support/values/time_zone.rb:270: warning: circular argument reference - now
/home/ec2-user/apps/foo_prod/shared/bundle/ruby/2.2.0/gems/ruby-ole-1.2.11.7/lib/ole/types/base.rb:265: warning: duplicated key at line 266 ignored: 4095
Use Rails 3.2.22
gem 'rails', '3.2.22'
OR
warning fixes in version 1.2.11.8:
bundle update ruby-ole
This is an issue of Active Support and has been fixed with these two commits:
https://github.com/rails/rails/commit/8fd52705eda6a2cd7e9a8a5bc723fa094e359eb7
https://github.com/rails/rails/commit/3a30b12c774dfaa72acfe520e823374131631ea9
Unfortunately, these commits have been never included into the 3.2 releases,
because the current last release (v3.2.21) was out on 18 Nov 2014
and after that these commits were merged.
If you don't want to see this warning message definitely, you should change
your Gemfile like this:
# gem 'rails', '3.2.21'
gem 'rails', git: 'https://github.com/rails/rails.git', branch: '3-2-stable'
Otherwise, you should downgrade ruby to 2.1 or wait the release of v3.2.22,
which won't come until a grave security hole is found.
After all, there is no easy way to avoid this issue. Changing Gemfile
for such a trivial annoyance may be an overreaction in my view.
It will delay your deployment process quite a lot.
I was not using compass in my application Based on this post here I upped my Rails version from 4.1.1 to 4.1.9 which worked.
This is compass issue here. They haven't release new version yet so you may need to wait for it.
here is what i did to resolve that, i had the latest ruby and the gems are not compatible with that, so after having a fight for nearly a day i switched to older ruby version using rvm
from ruby-2.2.1 to ruby-2.0.0 ,
again this is not an issue with ruby version but incompatibility with gems,try and have good luck with that.
Well, Here is a solution to this:
Try doing all these changes in your .rbenv/.rvm folder and change in these files:
https://github.com/tmm1/rails/commit/8fd52705eda6a2cd7e9a8a5bc723fa094e359eb7
Hypothetically, updating to Rails 4.2.0 - which you should be able to do via the following commands - should fix this error, although it hasn't worked for me:
rvm use ruby-2.2.0#rails4.2 --create
gem install rails
rails -v
I'm getting the same "circular argument error" message as well (I posted more about my failed attempts to fix it here, will update if I find an answer: Rails gem update not working (version 4.1.1 to 4.2.0) as a solution to "warning: circular argument reference" error).
I altered the time_zone.rb file, instead of now=now, I entered now=Time.now and problem solved.
I ran into the same issue as well, yo can sue the following steps to resolve it (worked for me).
$ gem uninstall compass
$ gem update --system
$ gem install compass

How to avoid commenting out ruby version in Gemfile while working locally?

It looks like heroku is now defaulting to using ruby 2.0.0 out of the box when you upload a rails app.
One of my gems breaks due to some incompatibility issue that I don't really want to look into. The solution is of course to write ruby '1.9.2' or what have you in the Gemfile.
Problem is when running the server locally, ruby() is only recognized by heroku, not your local bundler and so I have to comment it out every time while starting a local server.
Is there a clever way around this that I am not aware of?
Heroku's article about specifying ruby versions say this:
If you’re using a Bundler 1.1.4 or lower you’ll see the following
error:
undefined method `ruby' for #
(NoMethodError)
You’ll need to install bundler 1.2.0 or greater to use the ruby
keyword.
I think you just need to update your local bundler to 1.2.0 or greater, as mine (1.3.5) recognize the ruby directive just fine as well.

Ruby 1.8.7 works. Ruby 1.9.2 produces 'Trace/BPT trap: 5'

I am running a Rails 2.3.11 app on two versions of Ruby both installed with RVM. Both versions of Ruby have the exact same gems with the exact same versions for each. I uninstalled every gem that is not needed in the application.
Everything works fine with Ruby 1.8.7 (RVM 1.8.7).
Ruby 1.9.2 has two gemsets. RVM 1.9.2 has a gemset for another app. RVM 1.9.2#this_app has the gems listed below. With RVM 1.9.2#this_app I get:
Trace/BPT trap: 5
The log just stops with no indication of what the error is. Is there a gem compatibility issue? Here is the list of gems:
actionmailer (2.3.11)
actionpack (2.3.11)
activerecord (2.3.11)
activeresource (2.3.11)
activesupport (2.3.11)
devise (1.0.10)
google4r-checkout (1.0.6.1)
i18n (0.6.0)
json (1.6.1)
liquid (2.2.2)
money (3.7.1)
mysql (2.8.1)
rack (1.1.2)
rails (2.3.11)
rake (0.9.2)
rmagick (2.13.1)
warden (0.10.7)
Thanks for your help.
This seems to be the list of gems installed, not what is in your Gemfile.
How are you managing the gems and gemsets? You seem to be using bundler, that's good, but how are you switching between versions of ruby and gemsets? Are you using rvm or rbenv? Do you have a Gemfile?
If you are not using bundler, it is possible to do so with rails 2.3.11, it just takes a bit of work. I would highly recommend this so you can better manage your dependencies.
I would then look at getting rid of whatever you can from the Gemfile, bundle install to update, and then try running again.
For example, I don't think you need cgi_multipart_eof_fix anymore, depending on how you are deploying.
Other gems like god, rubygems-update, and rdoc are not generally used within the app, and are likely not germane.
So I take it that you can't even boot the app successfully with ruby ./script/server? It doesn't start up and then crash on the first request?
When Ruby starts crashing on you, the first thing to look at is whether you are using any binary (not pure Ruby) gems. Just looking at the above list, I believe that json, mysql, and rmagick may be binary. Comment them out temporarily from your Gemfile (if you have to comment out part of the application code, then do it). Try starting the app with bundle exec ruby ./script/server and see if it crashes. (I think json might be required by Rails, in which case you won't be able to disable that one.)
If you are only using pure Ruby gems, and Ruby is crashing on you, then you have likely found a bug in the interpreter itself. That's nothing to get scared about; if I was you I would roll my sleeves up, dive into the C source (clone it from github.com/ruby/ruby), and fix that thang! But if you don't have skills in C you might not want to attempt it.
If you want to try to debug the interpreter, the first thing is to find the point where it is crashing. For that, litter the startup code (such as application.rb, boot.rb, etc. with puts "got to #{__FILE__}:#{__LINE__}" calls and try to pinpoint exactly where the crash is happening. If need be, you can crack open your gems and add puts calls to them too (just go into the directory where RVM keeps the Ruby code and edit away).
Once you find the point where it is crashing, you can go into the C source and find the implementation of whatever platform method or construct the crash is coming from. To get more information on what is happening internally, add debug printf calls and recompile the interpreter with make && make install. (Note that messages from C-level printfs don't seem to interleave in quite the correct order with Ruby-level puts.) Temporarily edit your PATH so the newly compiled binary in your cloned ruby/bin directory will act as the system ruby.
If you can actually figure the problem out and contribute a patch to Ruby, that will mean some pretty good bragging rights for you!
Don't really like answering my own questions, but found the full answer which wasn't provided yet.
Part of the problem was rmagick compatibility. I commented out references to rmagick in the app but was still getting the same error.
The biggest contributing factor was that RVM installs rubygems 1.8.24. Anything over rubygems 1.6.x will not work with a rails 2.3.x app. The command 'rvm rubygems 1.6.2' installed a version that was compatible.

Resources