Remove monkey patching #1036

JonRowe · 2013-08-08T06:09:19Z

ATM I've defaulted to off in our specs, and on in the cucumbers, but we can discuss that if you disagree.

Thoughts?

/cc @alindeman @myronmarston @samphippen @soulcutter

JonRowe · 2013-08-12T17:49:33Z

Ping! Has anyone had a chance to start to review this yet?

myronmarston · 2013-08-12T17:57:11Z

I haven't yet...too busy with moving still. I'll try to get to it soon.

One general comment: there's also #870 where some work was started to make example group alias methods available at the top level. Does this PR fit in with that? I'd like to find a way to integrate that at some point.

JonRowe · 2013-08-13T21:42:15Z

I need to rework this to take advantage of #870 me thinks...

JonRowe · 2013-10-14T11:58:08Z

Ok so I'd like to get this sorted, and then take #870 back on top of this, I don't mind assisting or taking over from @michihuber to get these two across the line.

JonRowe · 2013-10-14T11:59:05Z

So a review would be good, then I'll sort squashing etc, at a minium a change log entry needs adding ;)

xaviershay · 2013-10-14T15:13:56Z

features/configuration/monkey_patching.feature

@@ -0,0 +1,44 @@
+Feature: Monkey patching
+
+  Use the monkey patching to tell RSpec to allow or disallow the top level dsl.


"the monkey patching" is funny, but should just be "monkey patching" to be correct. I don't mind one way or the other :)

I actually wonder if we should call this monkey patching at all, perhaps we should state that what this is doing more explicitly? How about:

Tell RSpec to expose the dsl via the global namespace.

myronmarston · 2013-10-15T16:53:10Z

The difficulty is finding "when" to do it, as I don't think it's feasible to remove monkey patching after its happened, so we need to do it at the last possible minute (before spec files are loaded).

You can always undefine the monkey-patched methods as we do in rspec-mocks and rspec-expectations, but that would require bare method defs rather than module inclusion/extension. And actually, I think I prefer the way you have it.

Hmm, actually, thinking about it some more: I'm not sure that the way you have it will work for end users. You add the monkey patches before loading the spec files. Most users who will disable this will disable it in spec_helper.rb, which will not be loaded and evaluated until load_spec_files loads a file that requires it.

So I think we probably want to move to a mechanism like rspec-mocks and rspec-expectatations. See the syntax files there.

Overall this is looking great. I want to hold off on merging this until we release our 3.0.0.alpha, though.

JonRowe · 2013-10-20T23:30:43Z

Okay, this has been reworked to change the name to expose_globally which defaults to true, and will enable / disable the top level stuff whenever it's invoked (no need for presetting)

JonRowe · 2013-10-20T23:49:03Z

Build failure is due to @alindeman's JRuby issue in rspec-mocks :/

xaviershay · 2013-10-21T03:11:22Z

features/configuration/enable_global_dsl.feature

+
+  Tell RSpec to expose the DSL via the global namespace
+
+  Scenario: by default RSpec allows the top level monkey patching


should update this text to enable global.

xaviershay · 2013-10-21T03:13:17Z

I want to hold off on merging this until we release our 3.0.0.alpha, though.

@myronmarston why?

myronmarston · 2013-10-21T06:54:34Z

features/configuration/enable_global_dsl.feature

+  Scenario: when exposing globally is disabled top level dsl no longer works
+    Given a file named "spec/example_spec.rb" with:
+      """ruby
+      RSpec.configure { |c| c.expose_globally = false }


You know, I'm not sure that expose_globally has the right sense. It's not exposed in the global scope like a global variable is. It's exposed at the top level scope off of main.

Also, from the config option name it's not clear what is being exposed.

What do you think about expose_dsl_off_of_main instead?

It's not just main though, it's also off Module (so you can nest describe inside modules/classes) so it is kind of globally... it's also too wordy for my liking.

I could go for expose_dsl though.

myronmarston · 2013-10-21T06:57:17Z

@xaviershay -- my primary concern is that I want a release to be consistent, without in-progress, half-done features. #870 is another aspect of this feature, I think, and it feels incomplete without that. As such, I don't want to have this merged and then block our being able to release a solid alpha. Once we ship that first alpha, it's fine to merge things like this that will have later PRs to round-out the features.

michihuber · 2013-10-21T06:59:40Z

@JonRowe, I'll keep an eye on this PR and resubmit #870 once this is ready for master.

JonRowe · 2013-11-10T23:52:53Z

So I rebased this and it broke horrifically. I'm at a loss as to what's changed in master that breaks this, my hunch is that it's something to do with the sandboxing going awry... See the diff or pull down the no_monkey_patch_rebased branch and run for yourself o_O

e.g. HALP

/cc @myronmarston @xaviershay @samphippen

JonRowe · 2013-11-14T07:56:32Z

Did anyone get a chance to look at my other branch? @myronmarston @xaviershay @samphippen

myronmarston · 2013-11-14T08:06:06Z

Not yet -- I'll take a look later this week.

myronmarston · 2013-11-15T03:00:07Z

I pulled your branch now and bisected it. b9adedd is the source commit that introduces the problems.

JonRowe · 2013-11-15T03:04:49Z

Yes, it's also the ~~first commit~~ commit that turns off monkey patching on this and that branch. However it hasn't changed since before I rebased it, where it works fine. There seem to be no related changes, the commit actually causing the failure lies between the point where I originally branched off and the current master.

My investigations have lead me to uncover that somehow run is being undefined from ExampleGroup subclasses or the subclasses themselves are not inheriting changes properly. My assumption is that this is somehow related to no longer mixing in our classes into the top level namespace.

myronmarston · 2013-11-20T02:15:45Z

@JonRowe -- would you like me to take this over or are you still planning to get to the bottom of the problem you're having?

e.g. * use RSpec.describe as opposed to describe * use RSpec DSL for shared examples

…g change*

…xposure)

JonRowe · 2013-12-02T05:36:16Z

FYI the methods are idempotent just Ruby issues a warning... additionally I've actually noticed the methods protect against this themselves making the configuration check a non issue. I've also moved the initial call to the only place we initialised Configuration. So by default it'll be set but for every other usage of Configuration.new it won't.

I personally read expose_globally as RSpec.expose_globally so it's clear to me, willing for other voices? @samphippen @xaviershay @soulcutter

myronmarston · 2013-12-02T05:50:43Z

spec/rspec/core/configuration_spec.rb

-        config_1 = Configuration.new
-        config_2 = Configuration.new
+        config_1 = Configuration.new.tap { |c| c.expose_globally = false }
+        config_2 = Configuration.new.tap { |c| c.expose_globally = false }


Given that new Configuration instances no longer set expose_globally = true, I think you no longer have to set expose_globally = false here (or in any of the other specs), right?

I think you're right, shall we drop them?

Please do. It's noise and it suggests that it's necessary when it's not, which leads to confusion.

myronmarston · 2013-12-02T06:06:02Z

FYI the methods are idempotent just Ruby issues a warning

Since we want rspec to be warning-free, can you fix it so ruby doesn't issue a warning?

I've also moved the initial call to the only place we initialised Configuration. So by default it'll be set but for every other usage of Configuration.new it won't.

👍

I personally read expose_globally as RSpec.expose_globally so it's clear to me, willing for other voices?

That doesn't seem any clearer to me: RSpec.expose_globally is telling RSpec to expose something globally but it doesn't say what should be exposed.

If others think it's perfectly clear I'm happy to go with what you have, though.

JonRowe · 2013-12-02T11:34:57Z

FYI the methods are idempotent just Ruby issues a warning

Since we want rspec to be warning-free, can you fix it so ruby doesn't issue a warning?

They are warning free, thats what the extra protective code is doing, I removed the var check from Configuration but it seems I'm also doing it in DSL so it's all fine.

myronmarston · 2013-12-02T16:48:06Z

They are warning free, thats what the extra protective code is doing, I removed the var check from Configuration but it seems I'm also doing it in DSL so it's all fine.

👍 I guess I misread your comment then. Thanks!

Anyhow, this is looking good to me. My concern about the expose_globally name remains but that'll really come down to what others think (@xaviershay? @alindeman? @samphippen? @soulcutter?). This also needs a changelog, then merge away.

myronmarston · 2013-12-02T16:49:07Z

Oh yeah, one other thing: the expose_globally config option could use some YARD doc comments explaining what it does. (But we can always address that in a separate PR; don't let that hold up the merge here).

[skip ci]

JonRowe · 2013-12-02T22:33:19Z

I added an additional line to the YARD explaining a bit more, I also changed my mind about the name of the config var.

JonRowe · 2013-12-02T23:23:48Z

I've moved the config line back to the sandboxing. My reasoning is that this is the easiest way to ensure consistent state across the spec run with regards to this setting. To me it makes much more sense to protect against this one setting here rather than run anything that touches RSpec.reset or RSpec.run in a sub process... WDYT @myronmarston?

Remove monkey patching

JonRowe · 2013-12-03T05:00:40Z

I decided if we need to refactor the specs thwn we can do that later.

JonRowe mentioned this pull request Aug 8, 2013

Add a "use_rspec_syntax" configuration option. #1034

Closed

ghost assigned JonRowe Oct 3, 2013

xaviershay reviewed Oct 14, 2013
View reviewed changes

xaviershay reviewed Oct 21, 2013
View reviewed changes

myronmarston reviewed Oct 21, 2013
View reviewed changes

yujinakayama mentioned this pull request Nov 13, 2013

Support conversion to non-monkey-patch #describe yujinakayama/transpec#22

Closed

myronmarston mentioned this pull request Nov 29, 2013

Allow top-level context #1204

Closed

JonRowe added 12 commits December 2, 2013 15:51

Use RSpec.#{method} for top level DSLs

2075b62

e.g. * use RSpec.describe as opposed to describe * use RSpec DSL for shared examples

Configure whether to expose DSL globally

98fc0ed

top level dsl under RSpec

a0e0a65

describe behaviour with/without global namespace DSL

bdf3f1c

monkey patching must be explicity enabled if using same file *breakin…

c032328

…g change*

supress warning

4bd801e

expose globally true/false

125d939

spec out isolated expose globally on/off

dd7eabb

describe at runtime configuration of global exposure

0005890

configure ignores for method cache prevention

55a7064

remove toplevel check for exposure (its also checked in the two DSL e…

c425dca

…xposure)

move config default to only usage

1ac02ab

myronmarston reviewed Dec 2, 2013
View reviewed changes

JonRowe added 3 commits December 3, 2013 09:07

remove config reconfiguration

aa9c1ff

documentation for expose_globally

a7fee30

[skip ci]

rename expose_globally to expose_dsl_globally

8740e3b

restore config to sandbox

1da935e

JonRowe added a commit that referenced this pull request Dec 3, 2013

Merge pull request #1036 from rspec/no_monkey_patch

9a1deb3

Remove monkey patching

JonRowe merged commit 9a1deb3 into master Dec 3, 2013

JonRowe deleted the no_monkey_patch branch December 3, 2013 04:59

myronmarston mentioned this pull request Dec 7, 2013

Aliasing API for #describe #870

Closed

		@@ -0,0 +1,44 @@
		Feature: Monkey patching

		Use the monkey patching to tell RSpec to allow or disallow the top level dsl.


		Tell RSpec to expose the DSL via the global namespace

		Scenario: by default RSpec allows the top level monkey patching

Remove monkey patching #1036

Remove monkey patching #1036

Conversation

JonRowe commented Aug 8, 2013

JonRowe commented Aug 12, 2013

myronmarston commented Aug 12, 2013

JonRowe commented Aug 13, 2013

JonRowe commented Oct 14, 2013

JonRowe commented Oct 14, 2013

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

myronmarston commented Oct 15, 2013

JonRowe commented Oct 20, 2013

JonRowe commented Oct 20, 2013

Choose a reason for hiding this comment

xaviershay commented Oct 21, 2013

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

myronmarston commented Oct 21, 2013

michihuber commented Oct 21, 2013

JonRowe commented Nov 10, 2013

JonRowe commented Nov 14, 2013

myronmarston commented Nov 14, 2013

myronmarston commented Nov 15, 2013

JonRowe commented Nov 15, 2013

myronmarston commented Nov 20, 2013

JonRowe commented Dec 2, 2013

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

myronmarston commented Dec 2, 2013

JonRowe commented Dec 2, 2013

myronmarston commented Dec 2, 2013

myronmarston commented Dec 2, 2013

JonRowe commented Dec 2, 2013

JonRowe commented Dec 2, 2013

JonRowe commented Dec 3, 2013