[#113107] [Ruby master Bug#19576] Backport request: Gemfile.lock resolving is broken with bundler shipped with Ruby 3.1.4 — "jprokop (Jarek Prokop) via ruby-core" <ruby-core@...>

Issue #19576 has been reported by jprokop (Jarek Prokop).

8 messages 2023/04/04

[#113112] [Ruby master Bug#19578] abort() shows stack trace when run within rescue clause — "Dan0042 (Daniel DeLorme) via ruby-core" <ruby-core@...>

Issue #19578 has been reported by Dan0042 (Daniel DeLorme).

8 messages 2023/04/04

[#113180] [Ruby master Feature#19588] Allow Comparable#clamp(min, max) to accept nil as a specification — "kyanagi (Kouhei Yanagita) via ruby-core" <ruby-core@...>

Issue #19588 has been reported by kyanagi (Kouhei Yanagita).

7 messages 2023/04/11

[#113209] [Ruby master Bug#19596] Decreased performance after upgrading from ruby 2.7.2 to ruby 3.2.2 — silva96 via ruby-core <ruby-core@...>

Issue #19596 has been reported by silva96 (Benjam=EDn Silva).

7 messages 2023/04/13

[#113238] [Ruby master Misc#19599] DevMeeting-2023-05-10 — "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>

Issue #19599 has been reported by mame (Yusuke Endoh).

14 messages 2023/04/14

[#113285] [Ruby master Bug#19607] Introduce `Hash#symbolize_keys`. — "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...>

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

8 messages 2023/04/18

[#113303] [Ruby master Feature#19610] GC.delay_promotion — "peterzhu2118 (Peter Zhu) via ruby-core" <ruby-core@...>

Issue #19610 has been reported by peterzhu2118 (Peter Zhu).

9 messages 2023/04/20

[#113313] [Ruby master Bug#19613] Add version information to all function documentation — "fulldecent (William Entriken) via ruby-core" <ruby-core@...>

Issue #19613 has been reported by fulldecent (William Entriken).

7 messages 2023/04/23

[#113342] [Ruby master Feature#19617] Add Method#binding and UnboundMethod#binding, similar to Proc#binding — "nevans (Nicholas Evans) via ruby-core" <ruby-core@...>

Issue #19617 has been reported by nevans (Nicholas Evans).

9 messages 2023/04/25

[#113381] [Ruby master Bug#19624] Backticks - IO object leakage — pineman via ruby-core <ruby-core@...>

Issue #19624 has been reported by pineman (Jo=E3o Pinheiro).

10 messages 2023/04/30

[ruby-core:113276] [Ruby master Bug#16951] Consistently referer dependencies

From: "iMacTia (Mattia Giuffrida) via ruby-core" <ruby-core@...>
Date: 2023-04-17 12:18:02 UTC
List: ruby-core #113276
Issue #16951 has been updated by iMacTia (Mattia Giuffrida).


@hsbt would it be possible to get an update on this? Has there been any progress over the past couple of years?

I'd like to share an ongoing issues that I believe is related to this: as a core maintainer of `faraday`, I'm being asked to add an explicit dependency to `net-http` in attempt to solve [this issue](https://github.com/ruby/net-imap/issues/16).
There are currently conflicting views on what the correct course of action should be:
1. Some, like the author of this issue, suggest gems should add an explicit dependency if they use a standard gem.
2. On the other side, I agree with @eregon that this will [only make things worse](https://github.com/ruby/net-imap/issues/16#issuecomment-1511133260), and that we should rely on Ruby loading the appropriate version of the library if this is a stdlib or standard gem.

Any direction or suggestion from the Ruby core team would really help figuring this out, so we can all start moving in the same direction.

----------------------------------------
Bug #16951: Consistently referer dependencies
https://bugs.ruby-lang.org/issues/16951#change-102837

* Author: vo.x (Vit Ondruch)
* Status: Assigned
* Priority: Normal
* Assignee: hsbt (Hiroshi SHIBATA)
* ruby -v: ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
It seems that the default gems interdependencies in Ruby are mess. Years ago, when JSON was merged into StdLib, there was big movement and everybody dropped their references to JSON "because it is part of StdLib and therefore it is not needed". I always thought that removing the references was mistake.

Now, there are other interesting cases. Let me name two I know about:

1) REXML is going to be removed from default gems in Ruby 2.8, so some packages already started to introduce the dependency explicitly [1]. So once somebody uses Kramdown on older Ruby, the external REXML of whatever version is going to be used.

2) There are also gems in StdLib, such as IRB, which are specifying their dependencies in .gemspec file.

This is unfortunately causing very inconsistent user experience, depending if RubyGems are enabled/disabled, if one is using Bundler or not, if somebody explicitly states something somewhere and what dependencies are transitively pulled in.

I would really appreciate, if Ruby upstream finally paid attention to this problem. My suggestion is that if some gem depends on some other gem, this dependency should be always explicitly stated in the .gemspec file. This would provide clear precedence and guideline to others. This would save all possible surprises and hidden issues, suddenly using dependency of different version, which is pulled in transitively.

[1]: https://github.com/gettalong/kramdown/commit/c1aa6ad98fab589050ab8e82897ec4b7a3850b89



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

In This Thread