Closed fdr closed 1 year ago
We only make monkey patches when using the monkey patching mode, you can turn this off in your configuration:
RSpec.configure { |c| c.disable_monkey_patching! }
This will be a future default but due to a chicken and egg problem still is enabled by default in RSpec 3.
If you still suffer this problem with this turned off please re-open.
Yeah, I do suffer this problem with it turned off. It's a new project; there is no inertia.
@JonRowe also, I don't think I have the permission to re-open an issue if it is closed by a collaborator.
You have to add the code snippet to turn it off in a new project
Also the stack trace seems to indicate zeitwerk, if this is a rails project see what happens with mini test, Rails is more likely to modify the core obects than us.
Have reproduced this myself without zeitwerk ~,but I'm confused as it seems to be coming from modification to one of our meta classes, which shouldn't be frozen as they aren't core~
On further investigation this fixes the snippet above:
require "stringio"
require "ripper"
require "refrigerator"
Refrigerator.freeze_core
So it's not RSpec but Ruby at fault for the modifications, we're just requiring files that we'd expect to work, and we do so when we need them to avoid early poisoning of the environment (and with fallbacks in some cases for when they're not available)..
I'm half inclinced to close this as "won't fix" but if you wanted to go through the code base and collect a list of all our requires then add a feature that preemptively loads them that something we could add to work around this (or you could just do it manually in your project)
wontfix is fine, this issue suffices, and I can contribute it to the roda-sequel stack template project. It has a few remarks for other common software (e.g. puma) that need a poke, though generally the poke is eagerly loading the library via require.
also, thank you.
Subject of the issue
I'd like to use
Refrigerator.freeze_core
to freeze core classes, ideally in both tests and at run-time (along with other classes that ought not to be changed past a certain point). RSpec has some unusual patterns in modifying core classes that makes requiring rspec before freezing inadequate to prevent a crash.Your environment
Steps to reproduce
In
spec_helper.rb
, add these to the bottom of the file:When running even a trivial test, rspec crashes as Object has been frozen by this point, but rspec still wants to make modifications. This is somewhat normal for some libraries, so the usual workaround is to "require" them first, but rspec seems to need something more.
Here's the stack and exception:
Expected behavior
RSpec should make all its core-classes changes somewhat more eagerly, or, it can document steps whereby I can force those steps to happen before freeze_core.
Actual behavior
It crashes, and it's not obvious how I can force rspec to make whatever standard library modifications it needs to before freezing.