Issue #16345 has been updated by sam.saffron (Sam Saffron).


I tried Jeremy's patch results are here of running Discourse `bin/turbo_rspec` it runs our test suite using 16 threads on my computer. 


2440 warning for every test run, suffice to say at Discourse we will absolutely turn this warning off after submitting tickets and waiting for them to be handled. Seeing anything that is not purposeful in the test runners logs interferes greatly with puts debugging.

https://gist.github.com/SamSaffron/724f821df9786a2ddd408202b950cb46

In a multithreaded setup "warn per thing" and even warn "once per type" and "warn by callsite" are still too noisy. In a single threaded app I can see "warn per thing" as useful sometimes.

A side effect of all this tracking is that there is a small perf penalty over doing no work at all. (3 million hash lookups) 

As for what Discourse will do regardless of what Ruby decide: 

- We will amend our default for quality of life for dev team not to warn by default unless you opt in via env, this sucks but we are going to simply run `def Warning.warn(str); end` this will be the case till the storm subsides, once we get it to 0 we will re-enable warnings. 

- In production we will not be warning on deprecations ever, due to risk of flooding logs so the same patch will apply, but it is permanent. Prob just add `RUBYOPT=-W0` to env for production for risk mitigation.

Technically there is nothing that is stopping us moving in this way when 2.7 is released. 

I am curious at what GitHub and Shopify will do here who both have reasonably big dev teams?

I do worry that the current state is dangerous: 

- When you upgrade your Ruby you can be presented with 3 million lines in STDERR for a process that runs for a couple of minutes it will be reported to the security mailing list as a flaw. 

- I worry that a huge increase in warnings will place enormous urgent pressure on gem maintainers. 

Overall this is a transient state so I defer to Matz on how to deal with this, as it stands if we ship 2.7 as it I am counting down 2 days before this is submitted to the security mailing list as a security flaw. 


----------------------------------------
Feature #16345: Don't emit deprecation warnings by default.
https://bugs.ruby-lang.org/issues/16345#change-82837

* Author: akr (Akira Tanaka)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
We propose that Ruby doesn't emit deprecation warnings by default.

Deprecation warnings are only useful during development for updating Ruby version.
They are not useful during development with current Ruby.
It is especially frustrating when deprecated warnings are generated in gems.
Also, deprecation warnings are totally useless in production environment.

So, we want to emit deprecation warnings only in useful situations.

We propose a command line argument `-W:deprecated` (or `--warning=deprecated`)
and the following methods to enable/disable deprecation warnings.

```ruby
Warning.disable(:deprecated)
Warning.enable(:deprecated)
Warning.enabled?(:deprecated)
```

Currently we don't propose a method to generate a deprecation warning
because currently our main intent is to disable deprecation warnings for 
keyword arguments, and the warnings are generated in C level.

Background:

We talked about keyword arguments during a developer meeting (2019-11-12).
https://bugs.ruby-lang.org/issues/16333
We expect many deprecation warnings to be generated in Ruby 2.7.
They are not useful except for development for Ruby transition, and
they may block transition to Ruby 2.7.

So, we have consensus to disable deprecation warnings by default.
Our design is intentionally minimum because we need this feature for Ruby 2.7.

We chose `Warning.disable(:deprecated)` instead of
re-defining `Warning.warn` in order to avoid string object generation.

Of course, we expect to extend this feature:
Ruby-level deprecation warning generation,
warnings other than deprecation, 
file-based restriction of warning generation, etc.
But this issue doesn't contain them.




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>