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

Issue #16951 has been updated by Eregon (Benoit Daloze).


deivid (David Rodr=EDguez) wrote in #note-1:
> Had dependant gems had their dependency explicited in their `gemspec` as =
`s.add_dependency "bigdecimal", "~> 1.0"`, no breakage would've occurred.

OTOH bigdecimal 1.x will probably not work on the newer Ruby versions, so i=
t's not great either.
But at least it'd break when trying to support a new Ruby version, not befo=
re, which is nice.

I'm concerned that C extensions of default gems are only tested against the=
 latest Ruby, and so e.g., might not work on older Rubies.

Also stdlibs can have a different implementation in alternative Ruby implem=
entations 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 install`.

The way forward is probably to explicitly handle alternative Ruby implement=
ations in all default gems as needed (which might be by using the vendored/=
stdlib version of BigDecimal on JRuby, but then it might not actually use t=
he expected version of bigdecimal).

Also, I feel not specifying dependencies of the stdlib gems is better in th=
e sense that it will use the version of the default gem that's shipped with=
 that Ruby, and was extensively tested.
Using any other version will not achieve the same level of testing, and ris=
k incompatibilities.

I guess any way long term all default/bundled gems will need support for al=
ternative implementations more explicitly, but right now it's just not the =
case.

Regarding TruffleRuby we plan to support default gems C extensions as much =
as possible, yet it might be difficult for some default gems because some o=
f them reach very deep in the MRI implementation, more than the average gem=
 with a C extension.

@headius Any thoughts on this?

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

* 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>