Issue #16951 has been updated by deivid (David Rodr=EDguez). > OTOH bigdecimal 1.x will probably not work on the newer Ruby versions, so= it's not great either. But at least it'd break when trying to support a ne= w Ruby version, not before, which is nice. This is the standard experience when your gem breaks on the newest rubies, = and as you point out it's better than the alternative. > I'm concerned that C extensions of default gems are only tested against t= he latest Ruby, and so e.g., might not work on older Rubies. Why is this if I may ask? I tend to recall the default gems upstreams testi= ng against several rubies according to their support range. > Also stdlibs can have a different implementation in alternative Ruby impl= ementations if wanted/needed, but that becomes not possible/hacky if there = is an explicit dependency on a default gem like bigdecimal ~> 1.0. Take the= example of JRuby and the bigdecimal gem for instance, it fails to gem inst= all. > The way forward is probably to explicitly handle alternative Ruby impleme= ntations in all default gems as needed (which might be by using the vendore= d/stdlib version of BigDecimal on JRuby, but then it might not actually use= the expected version of bigdecimal). I understand that there are some issues at the moment with default gems and= alternative implementations. In those cases, I agree it's probably better = to not specify requirements if you want to support the alternative implemen= tations. > Also, I feel not specifying dependencies of the stdlib gems is better in = the sense that it will use the version of the default gem that's shipped wi= th that Ruby, and was extensively tested. Using any other version will not achieve the same level of testing, and ris= k incompatibilities. I don't really buy this argument. The most stable version of a library shou= ld be the latest stable, because it includes the latest bug fixes, security= releases, and so on. I don't think that's a principle we should give up on= , specially since most default gems are still maintained by the core team i= tself. ---------------------------------------- Bug #16951: Consistently referer dependencies https://bugs.ruby-lang.org/issues/16951#change-86198 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * 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 ag= o, when JSON was merged into StdLib, there was big movement and everybody d= ropped their references to JSON "because it is part of StdLib and therefore= it is not needed". I always thought that removing the references was mista= ke. 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 pack= ages already started to introduce the dependency explicitly [1]. So once so= mebody 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 d= ependencies 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 somebo= dy explicitly states something somewhere and what dependencies are transiti= vely 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 wo= uld provide clear precedence and guideline to others. This would save all p= ossible surprises and hidden issues, suddenly using dependency of different= version, which is pulled in transitively. [1]: https://github.com/gettalong/kramdown/commit/c1aa6ad98fab589050ab8e828= 97ec4b7a3850b89 -- = https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>