[#113407] [Ruby master Feature#19630] [RFC] Deprecate `Kernel.open("|command-here")` due to frequent security issues — "postmodern (Hal Brodigan) via ruby-core" <ruby-core@...>

Issue #19630 has been reported by postmodern (Hal Brodigan).

19 messages 2023/05/05

[#113430] [Ruby master Feature#19633] Allow passing block to `Kernel#autoload` as alternative to second `filename` argument — "shioyama (Chris Salzberg) via ruby-core" <ruby-core@...>

Issue #19633 has been reported by shioyama (Chris Salzberg).

16 messages 2023/05/09

[#113489] [Ruby master Bug#19642] Remove vectored read/write from `io.c`. — "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...>

Issue #19642 has been reported by ioquatix (Samuel Williams).

10 messages 2023/05/15

[#113498] [Ruby master Feature#19644] Module::current to complement Module::nesting — "bughit (bug hit) via ruby-core" <ruby-core@...>

Issue #19644 has been reported by bughit (bug hit).

12 messages 2023/05/16

[#113517] [Ruby master Misc#19679] Migrate Wiki from bugs.ruby-lang.org to ruby/ruby GitHub repository — "jemmai (Jemma Issroff) via ruby-core" <ruby-core@...>

Issue #19679 has been reported by jemmai (Jemma Issroff).

11 messages 2023/05/18

[#113529] [Ruby master Bug#19681] The final classpath of partially named modules is sometimes inconsistent once permanently named — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>

Issue #19681 has been reported by byroot (Jean Boussier).

34 messages 2023/05/19

[#113538] [Ruby master Feature#19682] ability to get a reference to the "default definee" — "bughit (bug hit) via ruby-core" <ruby-core@...>

Issue #19682 has been reported by bughit (bug hit).

28 messages 2023/05/19

[#113601] [Ruby master Bug#19687] Should a development version of the standard library be included in ruby/ruby? — "jaruga (Jun Aruga) via ruby-core" <ruby-core@...>

Issue #19687 has been reported by jaruga (Jun Aruga).

9 messages 2023/05/23

[#113632] [Ruby master Bug#19691] Case insensitive file systems, require filename casing — "MSP-Greg (Greg L) via ruby-core" <ruby-core@...>

Issue #19691 has been reported by MSP-Greg (Greg L).

7 messages 2023/05/24

[#113656] [Ruby master Misc#19693] Data initialization is significantly slower than Struct — janosch-x via ruby-core <ruby-core@...>

Issue #19693 has been reported by janosch-x (Janosch M=FCller).

13 messages 2023/05/25

[#113660] [Ruby master Feature#19694] Add Regexp#timeout= setter — "aharpole (Aaron Harpole) via ruby-core" <ruby-core@...>

Issue #19694 has been reported by aharpole (Aaron Harpole).

15 messages 2023/05/25

[#113676] [Ruby master Bug#19697] Resolv::DNS resolution for international domains fails with "Encoding::CompatibilityError: incompatible character encodings: UTF-8 and ASCII-8BIT" — "clairity (claire c) via ruby-core" <ruby-core@...>

SXNzdWUgIzE5Njk3IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGNsYWlyaXR5IChjbGFpcmUgYykuDQ0K

6 messages 2023/05/27

[ruby-core:113679] [Ruby master Misc#17591] Test frameworks and REPLs do not show deprecation warnings by default

From: "byroot (Jean Boussier) via ruby-core" <ruby-core@...>
Date: 2023-05-27 09:55:15 UTC
List: ruby-core #113679
Issue #17591 has been updated by byroot (Jean Boussier).


Given that RSpec doesn't want to enable deprecation warnings by default, and that they were turned off mostly because the keyword related deprecations were very verbose, should we reconsider enabling them by default?

I kinda feel it's pointless going through deprecation cycles if a large part of the community is never warned that their code will break in the future...

----------------------------------------
Misc #17591: Test frameworks and REPLs do not show deprecation warnings by default
https://bugs.ruby-lang.org/issues/17591#change-103323

* Author: Eregon (Benoit Daloze)
* Status: Closed
* Priority: Normal
----------------------------------------
Various people in #16345 said that:
> The issue can be mitigated if all test frameworks enable all deprecation warnings.
> The developer's practice can be supported by tools, such as test frameworks enable deprecation warnings automatically.

And this was used as a base to disable deprecation warnings by default in Ruby 2.7.2.

However, it seems no test frameworks or REPLs actually show deprecation warnings by default!
So Ruby developers will typically never see deprecation warnings for keyword arguments, and it will just break when they try Ruby 3.0.

I think only MSpec does `Warning[:deprecated] = true`, whether or not `-w` is passed, which seems the right thing to do.

Currently, RSpec enables `Warning[:deprecated] = true` only for `rspec -w`.

Same for `test/unit` 3.3.4 shipped with 2.7.2.

IRB in 2.7.2 does not show deprecated warnings.
Same for `pry`.

I think ruby-core needs to have a clear message here, like:
> All test frameworks and REPLs should include this snippet and run it before running tests: `Warning[:deprecated] = true if Warning.respond_to?(:[]=)`.
> This is important so that developers see warnings in development, and that they see the warnings before updating to the next Ruby version.
> Developers can choose to disable deprecation warnings explicitly if they want with `Warning[:deprecated] = false`.

And I think it would be good that ruby-core makes a PR or an issue to the main test frameworks/REPLs to show examples.

P.S.: if someone wants to disable all warnings with `-W0` or `$VERBOSE = nil`, it will indeed disable them all, including deprecation warnings, so there is no need to check `$VERBOSE` for setting `Warning[:deprecated] = true`.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- [email protected]
 To unsubscribe send an email to [email protected]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

In This Thread