Ensure rspec core is loaded if rspec-rails is.

[xaviershay]

I don't think loading rspec/rails here is necessarily right, since Rails
might not be required yet and I don't think we should be the ones to
force that. Could be wrong here, but only loading rspec is more
conservative so choosing that for now.

Loading rspec seems important though, so that various version checks
work correctly.

See tpope/fivemat#29 for motivation.

[xaviershay]

@rspec/rspec I'm surprised we didn't do this already. Anyone know any relevant history?

[myronmarston]

@rspec/rspec I'm surprised we didn't do this already. Anyone know any relevant history?

I think we've never done this because it's generally not needed. The standard way to run RSpec is via rspec-core's rspec command, which loads rspec-core before doing anything else. Thus rspec-core is already loaded when rspec-rails gets loaded.

Having a require here doesn't cause any problems, of course, but I don't understand why it's necessary, either.

[xaviershay]

@myronmarston see linked fivemat issue for justification

[myronmarston]

I saw that, but I didn't quite understand yet. Here's what I understand so far:

• Fivemat registers either an rspec2 formatter or an rspec3 one when loaded based on detecting if rspec3 is loaded.
• The user is using bundler to autorequire gems (which I think is an anti-pattern...but I digress) causing rspec-rails and fivemat to be loaded by Bundler.require but not rspec-core since the user has not listed rspec-core in the Gemfile.

I get that, but what I don't understand is....how is Bundler.require getting invoked before rspec-core loads? Is the user running RSpec using a different, non-standard way than running the rspec command? With the rspec command, it loads rspec-core, then proceeds to load user files (which could eventually call Bundler.require).

I think whether or not we should do this depends on how the user is running RSpec and if its a way that we want to support.

[JonRowe]

There nothing in the linked issue to justify this, rails c test isn't an RSpec environment, why is fivemat even being loaded in that?

[myronmarston]

There nothing in the linked issue to justify this, rails c test isn't an RSpec environment, why is fivemat even being loaded in that?

Fivemat is loaded in that because of Bundler.require -- if the user has fivemat listed in their Gemfile without :require => false that's what it'll do.

[JonRowe]

I kind of feel fivemat should be solving this, maybe they should require it before checking?

[JonRowe]

Turns out this is a spring issue...

[fables-tales]

@rspec/rspec now this is green, are there any objections to merging this? It seems totally harmless to me, even if the justification is a little weird.

[myronmarston]

@rspec/rspec now this is green, are there any objections to merging this? It seems totally harmless to me, even if the justification is a little weird.

If this actually fixes the issue in question, we can merge it (although I'd want a comment one the line explaining why, since it's an odd line that shouldn't needed). If it does not fix the issue in question, I'd prefer we not merge it. I really dislike having lines of code that are "just in case" because there's a chance it might fix an issue for someone, but we're really not sure, and there's no test documenting the case it fixes.

[myronmarston]

I think we might want to consider reverting this. I believe it is the change that introduced #1645 and also changed the behavior of having rspec-rails in your Gemfile slightly, causing the issue reported in rspec/rspec-core#2301. IIRC, the consensus was that the issue we were trying to address was a bug in spring and I don't think we ever got confirmation that this change actually fixed anything.

Given that, should we revert this?

/cc @xaviershay @JonRowe @samphippen

[JonRowe]

You have my 👍 for a revert.

[xaviershay]

yeah revert it

On Fri, Jul 22, 2016, at 04:22 PM, Myron Marston wrote:

I think we might want to consider reverting this. I believe it is the
change that introduced #1645[1] and also changed the behavior of
having rspec-rails in your Gemfile slightly, causing the issue
reported in rspec/rspec-core#2301[2]. IIRC, the consensus was that
the issue we were trying to address was a bug in spring and I don't
think we ever got confirmation that this change actually fixed
anything.
Given that, should we revert this?
/cc @xaviershay[3] @JonRowe[4] @samphippen[5]
— You are receiving this because you were mentioned. Reply to this
email directly, view it on GitHub[6], or mute the thread[7].

Links:

1. irb: warn: can't alias context from irb_context. (3.5.0.beta4 and 3.5.0 final) #1645
2. disable_monkey_patching not preventing global alteration of describe rspec-core#2301
3. https://github.com/xaviershay
4. https://github.com/JonRowe
5. https://github.com/samphippen
6. Ensure rspec core is loaded if rspec-rails is. #1558 (comment)
7. https://github.com/notifications/unsubscribe-auth/AAAGsnMjSiyMbe6ZWevtEUfmYWkMcg_oks5qYVCygaJpZM4Hg-5G