Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please remove the ActiveSupport warning #1476

Closed
DannyBen opened this issue Sep 20, 2018 · 17 comments
Closed

Please remove the ActiveSupport warning #1476

DannyBen opened this issue Sep 20, 2018 · 17 comments
Milestone

Comments

@DannyBen
Copy link

if !$LOAD_PATH.grep(%r{gems/activesupport}).empty? && $LOADED_FEATURES.grep(%r{active_support/core_ext/hash}).empty?
puts <<-EOF
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.
EOF
end

Sinatra is used a lot as an embedded server. Now some of the tools that I have developed display this warning in the end result (i.e. to the user, not the developer).

I am not even including ActiveSupport directly in my gem, it is included through sinatra-contrib....

This type of message is suitable for documentation, not for runtime in my opinion.

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

@mwpastore
Copy link
Member

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?

@DannyBen
Copy link
Author

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.

@mwpastore
Copy link
Member

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.

@DannyBen
Copy link
Author

DannyBen commented Sep 20, 2018

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)...

@mwpastore
Copy link
Member

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?

@DannyBen
Copy link
Author

DannyBen commented Sep 20, 2018

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.

@mwpastore
Copy link
Member

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

@sammyhenningsson
Copy link

sammyhenningsson commented Sep 21, 2018

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!!

@mwpastore
Copy link
Member

mwpastore commented Sep 21, 2018 via email

@sammyhenningsson
Copy link

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.

@mwpastore
Copy link
Member

mwpastore commented Sep 22, 2018

@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.

@ginjo
Copy link

ginjo commented Oct 17, 2018

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?

@mwpastore
Copy link
Member

mwpastore commented Oct 17, 2018

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.

@ginjo
Copy link

ginjo commented Oct 17, 2018

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.

@SwagDevOps
Copy link

SwagDevOps commented Oct 18, 2018

Please remove ActiveSupport, from sinatra-contrib I mean.

@ZimbiX
Copy link

ZimbiX commented Oct 22, 2018

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.

@namusyaka
Copy link
Member

Closed via #1477

@namusyaka namusyaka added this to the v2.0.5 milestone Nov 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants