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

Issue #16951 has been updated by deivid (David Rodr=EDguez).


For what it's worth, I also agree that once a library is gemified and promo=
ted to a default gem, gems depending on it should add a sane explicit depen=
dency on them in their gemspec, protecting them, for example, from eventual=
 major version releases with breaking changes.

I've seen this kind of breakage, for example, with `BigDecimal 2.0` which r=
emoved `BigDecimal.new`. Had dependant gems had their dependency explicited=
 in their `gemspec` as `s.add_dependency "bigdecimal", "~> 1.0"`, no breaka=
ge would've occurred.

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

* 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:[e-mail]?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>