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>