These are chat archives for dry-rb/chat

1st
Jan 2016
Tim Riley
@timriley
Jan 01 2016 05:13
Trying to fix a bug in dry-component and the spec is intermittently failing. Something to do with the removal of constants from the Test namespace.
Actually, not exactly that, since when I disable the constant removal lines in spec_helper, it still intermittently fails...
Something to do with the run order.
Tim Riley
@timriley
Jan 01 2016 05:29
Weird – it looks like @_container is being persisted between spec examples...
I remember you mentioned this before, @solnic… /me searches
Hmmm. So _container’s got a different object_id for each example. Must be something else.
Ahhh, it’s because Kernel.require for my dependency (in auto_register! is returning false for my dependency in the new spec example I’ve added.
Tim Riley
@timriley
Jan 01 2016 05:34
which would suggest to me that it’s not reloading the class whose constant we’ve removed at the end of the previous example
I think the issue here is that I’ve used auto_register in my new container that I’m testing (it’s a test for auto-injecting objects from imported containers)
Tim Riley
@timriley
Jan 01 2016 05:40
Here’s the problem, AFAICT:
% echo "class Foo;end" > foo.rb

% irb                          
irb(main):001:0> require "./foo"
=> true
irb(main):002:0> Foo.new
=> #<Foo:0x007f885a02ea60>
irb(main):003:0> Object.send(:remove_const, :Foo)
=> Foo
irb(main):004:0> Foo.new
NameError: uninitialized constant Foo
    from (irb):4
    from /Users/tim/.rbenv/versions/2.3.0/bin/irb:11:in `<main>'
irb(main):005:0> require "./foo"
=> false
irb(main):006:0> Foo.new
NameError: uninitialized constant Foo
    from (irb):6
    from /Users/tim/.rbenv/versions/2.3.0/bin/irb:11:in `<main>'
irb(main):007:0>
If we’ve already required a file in a ruby process, then removing the constant and re-requiring the file doesn’t redefine the constant.
I think this hasn’t come up in container_spec so far because no constant has needed to be reused like this
Tim Riley
@timriley
Jan 01 2016 05:47
I’ve introduced an example that uses another fixture class with an include Import['…'] inside of it, and my change is one that sees imported containers get imported when doing that include, which means that my new fixture importable container gets imported by the existing spec with include Import[…], which causes the imported container’s constants to be removed, and then fail to be preoprly re-required/loaded for my new spec example
Ahhhh! $LOADED_FEATURES!
YESSSSSS
Tim Riley
@timriley
Jan 01 2016 05:53
Thanks for helping me out, rubber duckies.
Piotr Solnica
@solnic
Jan 01 2016 10:00
Yes I was aware of that issue in specs but didn't come up with a solution yet :)
Tim Riley
@timriley
Jan 01 2016 10:49
np :) Tweaking LOADED_FEATURES in the same way as you did LOAD_PATHS is probably good enough for specs as they are right now, but could be refined a little later on if needed.
Piotr Solnica
@solnic
Jan 01 2016 17:45
@timriley freaking global state right
Luca Guidi
@jodosha
Jan 01 2016 19:07
@timriley IIRC if you do load './foo', it forces the reload, without touching $LOADED_FEATURES.
Tim Riley
@timriley
Jan 01 2016 20:46
@jodosha yeah, thanks :) In my case though the production code is (rightly) using require, so I had to make that work.