Fix WrongScopeError

[pirj]

Fixes #2417
Related: #2215, rails/rails#37770

To test locally:
(pass)

bundle exec rake snippets

(fails, without the fix for WrongScopeError)

git checkout HEAD~1
bundle exec rake snippets

See #2417 (comment) for an explanation of at least one of the possible causes

[JonRowe]

This is a standalone reproduction that can be run in a rails app generated with rails new --minimal

require File.expand_path('../config/environment', __dir__)
ENV['RAILS_ENV'] ||= 'test'
require 'rspec/rails'

RSpec.configure do |config|
  config.use_active_record = false
end

class MyClass; end

RSpec.describe MyClass do
  it 'foo' do
    MyClass.new
  end
end

[benoittgt]

I will try to look at it if I have time around Christmas.

[benoittgt]

When people are using use_active_record = false they can have a rails app with still lot's of active_record loaded.

To reproduce the same behavior as in #2417. I had to de-comment require "active_record/railtie" in application.rb, then re-ad a database.yml then re-add sqlite in the Gemfile of the tmp/no-ar app.

I think the patch should be validated with another specs, closer to file_fixtures. I will keep searching for another proposal for your patch @pirj, if you have any idea. Feel free. :)

We could also change the no-ar-app but I think we may simply lack of specs on file_fixtures?

To reproduce the issue easily:

require "bundler/inline"

gemfile(true) do
  source "https://rubygems.org"

  git_source(:github) { |repo| "https://github.com/#{repo}.git" }

  gem "rails", "~> 6.1.0"
  gem "rspec-rails", "4.0.1"
  gem "sqlite3"
end

require "active_record/railtie"
require "logger"

require 'rspec/autorun'
require 'rspec/rails'

class Command
end

RSpec.configure do |config|
  config.use_active_record = false
end

RSpec.describe Command do
  it 'foo' do
    Command.new
  end
end

The commit responsible of the change is this one. rails/rails@d4367eb

[pirj]

Awesome find, @benoittgt !
I was stuck on adding a failing spec for that fix. Sounds like we could use yet another example_app_generator app, with AR (accidentally left) but use_active_record = false in our tests.
Did the fix above work for this reproduction snippet?

[benoittgt]

Hello @pirj

Did the fix above work for this reproduction snippet?

Yes, I can confirm it is working.

I am wondering if adding a new rails app isn't too much. 🤔 Trying to write a non regressive test similar to rails/rails@d4367eb#diff-76f5025b3bc6be04d08bb7df8f22ee2f0c69afe58aa4ba4933e6d6b9c328dc21R35-R38 could be an idea? What do you think?

[JonRowe]

I'd like us to be able to run snippets like @benoittgt's above within our build, I think they are easier to grok than the whole app builds for one spec; we shouldn't get ride of the app builds, they are important to demonstrate working generators etc but for one off issues like this it's easier if we can do ruby some_file.rb to test something

[benoittgt]

I love the idea. I wrote something similar recently :

The spec: https://github.com/WeTransfer/format_parser/blob/master/spec/active_storage/rails_app_spec.rb
The rails app: https://github.com/WeTransfer/format_parser/blob/master/spec/integration/active_storage/rails_app.rb

Do you think about something similar? If yes I can import similar code to rspec-rails code base.

[benoittgt]

Curious about your point of view on my last comment.

For the initial PR from @pirj I think we should try to at least add a spec on fixture_support ?

[pirj]

Awesome idea, @benoittgt ! If we reuse already installed gems and not re-download them, that should also work pretty quickly.
Not to say that otherwise our example_app_generator is getting pretty crowded.

[pirj]

@JonRowe @benoittgt Implemented the concept of testing snippets, added them to the build.

To test locally:
(pass)

bundle exec rake snippets

(fails, without the fix for WrongScopeError)

git checkout HEAD~1
bundle exec rake snippets

[pirj]

Snippets seem to be reusing spec/spec_helper.rb from our repo, and we don't want that.
A quick attempt to isolate it

   Dir.chdir('snippets') do
     Dir['*.rb'].each do |snippet|
       sh "echo Running #{snippet}"
       sh "ruby #{snippet}"
     end
    end

failed with:

[!] There was an error parsing `Gemfile`:
[!] There was an error parsing `Gemfile-rspec-dependencies`: No such file or directory @ rb_sysopen - /home/pirj/source/rspec-rails/snippets/maintenance-branch. Bundler cannot continue.

 #  from Gemfile-rspec-dependencies:1
 #  -------------------------------------------
 >  branch = File.read(File.expand_path("../maintenance-branch", __FILE__)).chomp

Adding an .rspec that doesn't --require spec_helper to snippets/ doesn't help, neither does adding a snippets/spec_helper.rb.

It also seems that sh ruby <snippet> from Rake suffers from the cached BUNDLE_GEMFILE issue, we have to reset it, otherwise, an attempt to load Gemfile is made. unset BUNDLE_GEMFILE doesn't help.

[benoittgt]

Great proposal. I love the idea to easily test behavior separately.

I had the similar issue with the spec_helper but in my case it was related to ammeter and loading issue. I will try to play tonight with it if you didn't find a solution yet.

[benoittgt]

I push a small change. I have some duplication on SQLite because we do not eval Gemfile. This could be moved somewhere I think, or in a dedicated file that we we could eval in both scenarios.

@pirj fill free to remove/squash it if you have better ideas. 😊

[JonRowe]

Does this definitely fail if it er... fails?

[pirj]

It does, yes.

[JonRowe]

Do we want to eventually extract this to snipets/gemfile.rb or similar? And require that?

[pirj]

@benoittgt Thanks a lot for fixing this, it seems to work!

There was a glitch,

/Users/pirj/.rvm/rubies/ruby-2.7.1/lib/ruby/2.7.0/bundler/runtime.rb:312:in `check_for_activated_spec!': You have already activated loofah 2.8.0, but your Gemfile requires loofah 2.9.0. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)

but it resolved after:

$ bundle update --conservative loofah
Using loofah 2.9.0 (was 2.8.0)

It seems that if any of the dependencies with flexible version constraints update, we have to keep the repo's Gemfile.lock up to date to keep them in sync to avoid version mismatches.

I'll play around with it, maybe something like

require 'bundle/setup'

helps.