Reload hooks when metadata changes #1089

JonRowe · 2013-09-30T23:04:13Z

This is a trivial take at solving rspec/rspec-rails#829 but simply watching for metadata changes
and then applying hooks again when they change. Hooks shouldn't be included twice due to the
checks in the existing call.

Simply moving the call to register the hooks didn't work due to ordering on the hooks.

Thoughts? /cc @myronmarston

myronmarston · 2013-09-30T23:31:11Z

I think I'd rather see the hook registration delayed until they are actually needed, as I suggested in the rspec-rails issue:

One idea is to move the hooks.register_globals call out of set_it_up and into run, so that the hooks are registered at the last possible moment.

Any reason that won't work? Seems far less complex, and would perform better.

JonRowe · 2013-09-30T23:32:02Z

It completely buggers the ordering, this is actually a far simpler change.

myronmarston · 2013-09-30T23:42:53Z

It completely buggers the ordering, this is actually a far simpler change.

Can you expand on that a bit? I'm not following...

JonRowe · 2013-09-30T23:45:20Z

Moving the call to run means that the hooks from the configuration will run after local hooks (not desirable).

So I attempted to solve this by changing how the hooks are added to the array but then local hooks are just intermingled with the configuration hooks, so I moved the registration call to the hook methods so it's a "JIT" registration of hooks, however this messes with the ordering of hooks in nested contexts.

JonRowe · 2013-09-30T23:46:59Z

So at this point the best place to load the configuration hooks is actually in the existing place, and then load in any extra hooks on metadata changes, or rewrite the hook system so we have more control over the ordering. The later is more complexity and more overhead.

myronmarston · 2013-10-01T00:04:53Z

lib/rspec/core/metadata.rb

+      def []=(key, value)
+        super
+        @callback.call if defined?(@callback)
+      end


There are other ways to change an metadata hash, right? Such as store, or any of the xyz! methods. Should the on_change hook be triggered for them?

This is the only one we use AFAIK but yes they should all follow this pattern, I'll go over the enum spec and add them all.

I've updated this for the ones that set metadata, this doesn't deregister hooks at the moment (that would require more changes, do we want to support that?)

I don't think we need to deregister hooks. on_change is private, anyway.

I've updated this for the ones that set metadata,

What about delete, delete_if, select! and reject!?

They don't set metadata, but remove it, hence my comment

this doesn't deregister hooks at the moment (that would require more changes, do we want to support that?

I'm ok with that too, or even just publicly stating we only support adding to metadata. If we stopped inheriting from hash and delegating to an internal hash we could control the api and reject those methods totally.

It'd be good to merge this PR soon, but I'd still like others to weight in (I'm still very much on the fence). @xaviershay? @samphippen? @soulcutter?

I'm OK stating that it's not intended to be a public API but is just intended for use by rspec-rails and is subject to change in a minor release.

This. We should collect stronger use-cases before exposing this publicly.

Reading this more, seems like we're between a rock and a hard place. We've exposed a full Hash as our interface, so are at the mercy of future versions of ruby to keep the method signatures that we're overriding for dirty tracking the same.

Seems like since we already have an iteration over methods in the latest version, it would be straight forward to just add the extra methods there.

myronmarston · 2013-10-01T00:07:15Z

Thanks, @JonRowe, after hearing you explain that this definitely seems like the right direction. Left a few comments.

JonRowe · 2013-10-01T09:49:59Z

@myronmarston I've addressed the issues commented about

myronmarston · 2013-10-01T15:12:54Z

Looks good...seems like you are missing a few mutation methods, though (see above).

myronmarston · 2013-10-01T15:15:45Z

lib/rspec/core/metadata.rb

+
+      [:[]=, :store, :merge!].each do |name|
+        define_method(name) do |*args|
+          super(*args)


merge! accepts a block:

http://www.ruby-doc.org/core-2.0.0/Hash.html#method-i-merge-21

I think that it gets forwarded automatically via super, but it would be good to spec that.

JonRowe · 2013-10-01T22:07:32Z

Looks good...seems like you are missing a few mutation methods, though (see above).

The other mutation methods only remove things from the hash, there's currently nothing to remove hooks when you remove metadata anyway. I left off the other mutation methods to make this more apparent. (See above)

myronmarston · 2013-11-02T19:28:24Z

spec/rspec/core/example_group_spec.rb

@@ -156,6 +156,19 @@ def ascending_numbers
        expect(examples_run.count).to eq(1)
      end

+      it "still runs matching config hooks when metadta is added later" do


s/metadta/metadata/

xaviershay · 2013-11-02T21:15:59Z

Rebased and added extra mutation methods. Note that overriding update doesn't work like the other ones (totally breaks), haven't figured out why yet.

xaviershay · 2013-11-02T21:18:55Z

oop, forgot about compat for old versions again :/

xaviershay · 2013-11-03T00:44:35Z

Given that this is not a new feature, and that Jon is away all weekend, I'm going to argue that this should not be a blocker for 3.0.0 pre. Any objections?

JonRowe · 2013-11-04T23:07:05Z

Thanks for adding the extra mutation methods @xaviershay, any ideas on how to actually make this work in those situations? (e.g. actually remove now unnecessary hooks?)

Only need to guard the spec, real code will be harmless.

xaviershay · 2013-11-05T03:27:46Z

Ah I see, I didn't understand the problem. Going to think about this after 3-pre. If you wanted to mark as private and merge without the extra mutation methods I'd be ok with that.

JonRowe · 2013-11-06T04:43:08Z

WDYT @myronmarston? Merge without the mutation methods? Or at least with the mutation methods marked as private...?

myronmarston · 2013-11-06T04:45:42Z

IIRC, this is fixing a bug in rspec-rails 2.14, right? Let's merge this in some form ASAP. I'm not sure what "with the mutation methods marks as private" means -- the metadata object is a hash, and the mutation methods are part of a hash's public interface. What do you mean by that?

JonRowe · 2013-11-06T04:59:50Z

Following on from @xaviershay's suggestion, they're public for Hash we don't have to make them public for MetaData

myronmarston · 2013-11-06T05:21:35Z

Following on from @xaviershay's suggestion, they're public for Hash we don't have to make them public for MetaData

Hmmm...I don't think we can do that in RSpec 2.x -- it would violate semver. We can do it in RSpec 3, but I'm wondering if there's a better approach we can do in 3.0? Can we change how rspec-rails does it's inclusion (maybe along the lines of rspec/rspec-rails#662) so that this is unnecessary?

JonRowe · 2013-11-14T07:42:16Z

@myronmarston However we solve rspec-rails (I still think this is the easiest way) we should either fix this or make metadata immutable. As it stands it's confusing IMO.

myronmarston · 2014-03-15T20:45:22Z

@JonRowe -- clearly this solution isn't going to work with the metadata hash just being a raw hash...we should figure out an alternate solution. Keeping open for now until we figure that out.

JonRowe · 2014-03-15T21:27:34Z

I think we need an api to mutate the hash, that triggers the hook inclusion et al, then rspec-rails can call that instead

myronmarston · 2014-03-15T21:36:55Z

I think we need an api to mutate the hash, that triggers the hook inclusion et al, then rspec-rails can call that instead

What kind of API do you have in mind? I'm having trouble coming up with a non-clunky API for that.

Here's an alternate idea I presented in #1231:

RSpec.configure do |rspec|
  rspec.define_inferred_metadata do |metadata|
    metadata[:type] = type_for(metadata[:file_path])
  end
end

Basically, rather than officially supporting all metadata features when you mutate metadata after the fact, provide an API to allow inferred metadata entries (which rspec-rails currently mutates the metadata to achieve), and rspec-core will ensure the inferred entries are set before it does anything with the metadata.

JonRowe · 2014-03-15T22:33:54Z

Here's an alternate idea I presented in #1231:

👍

myronmarston · 2014-03-20T06:19:19Z

@JonRowe -- whatever we come up with should address #969 as well.

myronmarston · 2014-04-21T20:55:34Z

Closing in favor of #1496

Fixes #969 and supercedes #1089.

Fully supporting metadata mutation is fraught with difficulties see (rspec/rspec-rails#829 and the attempted fix in #1089). For RSpec 3, we decided to expose `define_derived_metadata` as an officially supported way to accomplish the sorts of things metadata mutation was used for in RSpec 2. This spec got left behind (since it was passing at the time, it wasn't noticed) but isn’t something we want to support going forward since module inclusion shouldn't mutate metadata. It’s also getting in the way of a perf optimization I'm implementing.

Fully supporting metadata mutation is fraught with difficulties see (rspec/rspec-rails#829 and the attempted fix in rspec#1089). For RSpec 3, we decided to expose `define_derived_metadata` as an officially supported way to accomplish the sorts of things metadata mutation was used for in RSpec 2. This spec got left behind (since it was passing at the time, it wasn't noticed) but isn’t something we want to support going forward since module inclusion shouldn't mutate metadata. It’s also getting in the way of a perf optimization I'm implementing.

JonRowe added a commit to rspec/rspec-rails that referenced this pull request Sep 30, 2013

cleanup and remove own solution (depends on rspec/rspec-core#1089)

e8475dc

myronmarston reviewed Oct 1, 2013
View reviewed changes

JonRowe mentioned this pull request Oct 1, 2013

Run before(:all) hooks for rails magic example groups rspec/rspec-rails#829

Closed

myronmarston reviewed Oct 1, 2013
View reviewed changes

xaviershay mentioned this pull request Nov 2, 2013

Release 2.99 and 3.0.0 ALPHA #1136

Closed

13 tasks

myronmarston reviewed Nov 2, 2013
View reviewed changes

JonRowe and others added 9 commits November 5, 2013 10:14

example showing how configured metadata should be treated

0f1da29

reload hooks on metadata change

9c4398c

update metadata from setter methods

34e8f0f

spec block on #merge!

8c962c0

s/metadta/metadata/

4550ee4

Add extra hash mutation methods.

f1eff98

Handle more mutation methods.

d027fff

1.8 compact.

647e0bf

Only need to guard the spec, real code will be harmless.

spec proving mutation issue

d212027

JonRowe mentioned this pull request Mar 2, 2014

Stop subclassing Hash #1231

Closed

myronmarston added the Release blocker label Mar 24, 2014

This was referenced Apr 21, 2014

Make filetype infer opt-in rspec/rspec-rails#970

Merged

Define derived metadata. #1496

Merged

myronmarston closed this Apr 21, 2014

JonRowe deleted the reload_hooks_on_metadata_change branch April 21, 2014 22:19

myronmarston added a commit that referenced this pull request Apr 22, 2014

Add config.define_derived_metadata.

ebf9c80

Fixes #969 and supercedes #1089.

Reload hooks when metadata changes #1089

Reload hooks when metadata changes #1089

Conversation

JonRowe commented Sep 30, 2013

myronmarston commented Sep 30, 2013

JonRowe commented Sep 30, 2013

myronmarston commented Sep 30, 2013

JonRowe commented Sep 30, 2013

JonRowe commented Sep 30, 2013

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

myronmarston commented Oct 1, 2013

JonRowe commented Oct 1, 2013

myronmarston commented Oct 1, 2013

Choose a reason for hiding this comment

JonRowe commented Oct 1, 2013

Choose a reason for hiding this comment

xaviershay commented Nov 2, 2013

xaviershay commented Nov 2, 2013

xaviershay commented Nov 3, 2013

JonRowe commented Nov 4, 2013

xaviershay commented Nov 5, 2013

JonRowe commented Nov 6, 2013

myronmarston commented Nov 6, 2013

JonRowe commented Nov 6, 2013

myronmarston commented Nov 6, 2013

JonRowe commented Nov 14, 2013

myronmarston commented Mar 15, 2014

JonRowe commented Mar 15, 2014

myronmarston commented Mar 15, 2014

JonRowe commented Mar 15, 2014

myronmarston commented Mar 20, 2014

myronmarston commented Apr 21, 2014