'check_version_conflict': using 'rails new', with a version, when Rails 5.1.X installed #29113

roberts1000 · 2017-05-16T18:47:34Z

Steps to reproduce

Make sure Rails 5.0.3 is installed on the system. Uninstall Rails 5.1.0 and Rails 5.1.1 (along with all of their component gems). Run

rails _5.0.3_ new foo --skip-bundle

Everything works fine. Now install Rails 5.1.1. Run the same command

rails _5.0.3_ new foo --skip-bundle

Expected behavior

rails new should be to create a Rails 5.0.3 application.

Actual behavior

rails new crashes with the following error in the console

.../.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/specification.rb:2278:in `check_version_conflict': can't activate activesupport-5.1.1, already activated activesupport-5.0.3 (Gem::LoadError)

System configuration

Rails version: See above

Ruby version: Tested with Ruby 2.3.4 and 2.3.3.

The text was updated successfully, but these errors were encountered:

deivid-rodriguez · 2017-05-18T09:59:23Z

Just run into this too. But it seems like a rubygems problem?

djonasson · 2017-05-19T07:42:10Z

I just had the same problem with Ruby 2.3.1-p112 but with 2.3.3-p222 it worked.

ssaunier · 2017-05-23T21:38:32Z

I just had this problem as well. I use rbenv on OSX. On Ruby 2.4.1 I get this error message:

$ gem list | grep "^rails ("                                                                                                                                          
rails (5.1.1, 5.0.2, 5.0.1)

$ rails _5.0.2_ new test-50                                                                                                                                           
/usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/specification.rb:2278:in `check_version_conflict': can't activate activesupport-5.1.1, already activated activesupport-5.0.2 (Gem::LoadError)
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/specification.rb:1404:in `activate'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:89:in `block in require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:88:in `each'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:88:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/concurrent-ruby-1.0.5/lib/concurrent.rb:15:in `<top (required)>'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/activesupport-5.0.2/lib/active_support/logger_silence.rb:3:in `<top (required)>'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/activesupport-5.0.2/lib/active_support/logger.rb:1:in `<top (required)>'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/activesupport-5.0.2/lib/active_support.rb:27:in `<top (required)>'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/railties-5.0.2/lib/rails/generators.rb:6:in `<top (required)>'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/railties-5.0.2/lib/rails/commands/application.rb:1:in `<top (required)>'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/railties-5.0.2/lib/rails/cli.rb:14:in `<top (required)>'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /usr/local/opt/rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/railties-5.0.2/exe/rails:9:in `<top (required)>'
	from /usr/local/opt/rbenv/versions/2.4.1/bin/rails:22:in `load'
	from /usr/local/opt/rbenv/versions/2.4.1/bin/rails:22:in `<main>'

matthewd · 2017-05-24T02:22:47Z

Yeah, this seems to be a RubyGems problem.

AFAICS there are two things in play:

firstly, the "requirable file" cache doesn't get updated when a miss triggers a gem activation, so the file that originally triggered the gem to activate (in this case, concurrent/map) never gets the fast-path, and instead falls through to find_in_unresolved_tree. That seems to have some less-than-ideal performance implications, but only becomes a Real Problem here because:
secondly, find_in_unresolved_tree relies on has_conflicts? to filter plausible-sounding paths to the desired gem, and ends up choosing a path through a newer version of activesupport, even though another has already been activated, because has_conflicts? checks the dependencies of loaded gems, but doesn't check for a different version of that gem itself having already been loaded.

Throwing:

return true if already = Gem.loaded_specs[name] and not already.version == version

into has_conflicts? seems to make things happier for me, but I don't know enough about RubyGems to opine on the wider implications.

a-barbieri · 2017-06-07T06:09:56Z

Issue is closed, but I haven't understood how to solve to problem...

kent · 2017-06-08T11:15:28Z

Agreed, any reproducible fix?

kent · 2017-06-08T11:24:10Z

@a-barbieri I did the following and it worked.

Re-install rbenv distro you want (I chose 2.3.1)
cd apps
rbenv local 2.3.1
gem update --system
rails new whatever

So it could very well be an rbenv / rubygems issue. I tried just remove RubyGems and starting over and that didn't work. Only when I re-installed the rbenv distro did it work.

Hope that helps.

a-barbieri · 2017-06-08T13:01:26Z

Thanks @kent, I'm using RVM, but I guess this won't make any difference. I'll go through the re-installation process as soon as I have some spare time.

At the moment I simply avoided using rails new command and just copy/pasted Rails from another app.

tfogg2 · 2017-06-13T15:34:42Z

A simple 'gem update rails' solved this problem for me.

a-barbieri · 2017-06-14T08:38:58Z

That did it for me as well.

YaEvan · 2017-06-19T01:50:34Z

The same problom for me. I fix it by use
gem uninstall activesupport --version=5.1.1

emekdahl · 2017-06-20T13:05:45Z

'gem update rails' also worked for me!

Liqiankun · 2017-06-24T03:03:26Z

'gem update rails' does not work for me!

Liqiankun · 2017-06-24T03:14:15Z

@YaEvan It works for me!

gglaine · 2017-10-03T21:12:59Z

gem update rails - way to go !

sophiav · 2017-11-19T18:44:38Z

just tried gem update rails and it worked for me too..

roberts1000 changed the title ~~'check_version_conflict' using rails new, with a version, when Rails 5.1.X installed~~ 'check_version_conflict': using 'rails new', with a version, when Rails 5.1.X installed May 16, 2017

matthewd closed this as completed May 24, 2017

matthewd mentioned this issue May 24, 2017

'check_version_conflict': using 'rails new', with a version, when Rails 5.1.X installed rubygems/rubygems#1931

Closed

y-yagi mentioned this issue Jun 26, 2017

rails new with version specified fails if newer version installed #29577

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

'check_version_conflict': using 'rails new', with a version, when Rails 5.1.X installed #29113

'check_version_conflict': using 'rails new', with a version, when Rails 5.1.X installed #29113

roberts1000 commented May 16, 2017 •

edited

deivid-rodriguez commented May 18, 2017

djonasson commented May 19, 2017

ssaunier commented May 23, 2017

matthewd commented May 24, 2017

a-barbieri commented Jun 7, 2017

kent commented Jun 8, 2017

kent commented Jun 8, 2017

a-barbieri commented Jun 8, 2017

tfogg2 commented Jun 13, 2017

a-barbieri commented Jun 14, 2017

YaEvan commented Jun 19, 2017

emekdahl commented Jun 20, 2017

Liqiankun commented Jun 24, 2017

Liqiankun commented Jun 24, 2017

gglaine commented Oct 3, 2017

sophiav commented Nov 19, 2017

'check_version_conflict': using 'rails new', with a version, when Rails 5.1.X installed #29113

'check_version_conflict': using 'rails new', with a version, when Rails 5.1.X installed #29113

Comments

roberts1000 commented May 16, 2017 • edited

Steps to reproduce

Expected behavior

Actual behavior

System configuration

deivid-rodriguez commented May 18, 2017

djonasson commented May 19, 2017

ssaunier commented May 23, 2017

matthewd commented May 24, 2017

a-barbieri commented Jun 7, 2017

kent commented Jun 8, 2017

kent commented Jun 8, 2017

a-barbieri commented Jun 8, 2017

tfogg2 commented Jun 13, 2017

a-barbieri commented Jun 14, 2017

YaEvan commented Jun 19, 2017

emekdahl commented Jun 20, 2017

Liqiankun commented Jun 24, 2017

Liqiankun commented Jun 24, 2017

gglaine commented Oct 3, 2017

sophiav commented Nov 19, 2017

roberts1000 commented May 16, 2017 •

edited