If you disagree, at least please give a developer a way to disable it, please...

Would an environment variable be an acceptable way of doing this?

If you ask me, this "fix" creates more issues than it solves, and users should not be required to do anything to make it stop showing a warning, that they can do nothing about...

Don't get me wrong, I have mad respect for all the free time people put into open source, and Sinatra is one of my favorite Ruby projects, but - as an open source developer myself - I think we all need to remember that people are depending on what we do, and printing developer related warnings to stdout seems a little aggressive and out of place.

That said, if I failed to "pull you to my side of the table" - yes, an environment variable was what I had in mind, since it can be easily set up at the top level of anything that uses it, without touching any intermediate code layers.

There are some horrifyingly subtle bugs that can happen here if you don't get the code ordering just so. It didn't make sense (to me) to bury the warning in a piece of documentation that no one will ever read. I agree that it is aggressive and ugly, but I disagree that it "creates more issues than it solves."

I'm definitely open to alternative solutions and will defer to the Sinatra team on this issue. An opt-out environment variable is probably the easiest and most portable "workaround," if a bit kludgy. We could only show the warning in dev and/or test. We could print to stderr instead of stdout. Or some combination of these.

A neat solution would be to defer the check until the app is completed booted and then compare the signatures of Hash and Sinatra::IndifferentHash to see if the former has been monkey-patched but not the latter (e.g. #slice is defined on Hash but not Sinatra::IndifferentHash), indicating a condition where the aforementioned footguns may be possible. However, I don't believe there's an easy, portable way to hook onto an "app is finished loading" event.

Ok..... just note that for me at least, changing the warning to only show in non production is not going to cut it (unless it is also deferred to actual boot). In my command line utilities that happen to have Sinatra as the driver behind one of their sub commands, this warning will always show - like this:

$ madness --help
WARNING: If you plan to load any of ActiveSupport's core extensions to Hash, be
sure to do so *before* loading Sinatra::Application or Sinatra::Base. If not,
you may disregard this warning.
Madness

Usage:
  madness [PATH] [options]
  madness create config
  madness create theme FOLDER
  madness (-h|--help|--version)

...(truncated)...

We only need to show the warning message on older Rubies, so maybe that's a step we can take immediately. What version of Ruby are you running under?

We only need to show the warning message on older Rubies

This sounds great. Which is the highest version that requires this warning?
I am personally using 2.5.0, but I develop gems that support back to the area of 2.2.2 usually.

Anything under 2.5 could potentially be monkeypatched by ActiveSupport and break IndifferentHash.

I don't understand how this is supposed to work. My tests are now failing in TravisCI since I don' have activesupport installed. If activesupport is now a required dependency, then please add it to the gemspec!!

Now that ActiveSupport is used in IndifferentHash I think it should be a dev dependency for Sinatra.
I have a project that does not use neither Sinatra::Contrib nor ActiveSupport. Since 2.0.4, my tests are now failing because Sinatra is trying to load ActiveSupport.

@sammyhenningsson ActiveSupport is not used by IndifferentHash and it was never intended to be a dependency, but yes, there is a bug in the logic that conditionally requires ActiveSupport (to solve an error in Sinatra's internal testing suite), and it should be resolved by #1477.

EDIT: If you want to know more about the history of this issue, here is a deeper discussion.

What if the warning were to show ONLY when the gems load in a way that could cause problems? And if we follow the warning's instructions to load the gems in a specific order, the warning would go away.

Would this even be possible, or would it create as many problems as it solves?

What if the warning were to show ONLY when the gems load in a way that could cause problems?

This is impossible, because you may have ActiveSupport in your bundle for some purpose other than its core extensions to Hash, and there's no way for Sinatra to determine whether you are deliberately not loading the core extensions to Hash, or whether you intend to load them and just haven't yet.

And if we follow the warning's instructions to load the gems in a specific order, the warning would go away.

If you choose to load ActiveSupport's core extensions to Hash, and load them before requiring Sinatra, the warning will not show.

Thanks @mwpastore , that makes sense. I just stumbled upon one of my apps that does not show the warning, so that must mean I've somehow loaded the ActiveSupport extensions to Hash. I'm guessing Sinatra-contrib triggered that.

Please remove ActiveSupport, from sinatra-contrib I mean.

Here's the least uncomfortable workaround I could think of:

# Suppress Sinatra's Active Support warning by tricking it into thinking Active Support's Hash extensions are already loaded
# TODO: Remove once the Sintra resolves the issue: https://github.com/sinatra/sinatra/issues/1476
$LOADED_FEATURES << 'fake/active_support/core_ext/hash'

Once Active Support is removed from sinatra-contrib, this will be irrelevant.

Closed via #1477