https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112020-06-11T13:31:17ZRuby Issue Tracking SystemRuby master - Bug #16951: Consistently referer dependencieshttps://bugs.ruby-lang.org/issues/16951?journal_id=860952020-06-11T13:31:17Zdeivid (David Rodríguez)
<ul></ul><p>For what it's worth, I also agree that once a library is gemified and promoted to a default gem, gems depending on it should add a sane explicit dependency on them in their gemspec, protecting them, for example, from eventual major version releases with breaking changes.</p>
<p>I've seen this kind of breakage, for example, with <code>BigDecimal 2.0</code> which removed <code>BigDecimal.new</code>. Had dependant gems had their dependency explicited in their <code>gemspec</code> as <code>s.add_dependency "bigdecimal", "~> 1.0"</code>, no breakage would've occurred.</p> Ruby master - Bug #16951: Consistently referer dependencieshttps://bugs.ruby-lang.org/issues/16951?journal_id=861742020-06-15T18:59:05ZEregon (Benoit Daloze)
<ul></ul><p>deivid (David Rodríguez) wrote in <a href="#note-1">#note-1</a>:</p>
<blockquote>
<p>Had dependant gems had their dependency explicited in their <code>gemspec</code> as <code>s.add_dependency "bigdecimal", "~> 1.0"</code>, no breakage would've occurred.</p>
</blockquote>
<p>OTOH bigdecimal 1.x will probably not work on the newer Ruby versions, so it's not great either.<br>
But at least it'd break when trying to support a new Ruby version, not before, which is nice.</p>
<p>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.</p>
<p>Also stdlibs can have a different implementation in alternative Ruby implementations if wanted/needed, but that becomes not possible/hacky if there is an explicit dependency on a default gem like bigdecimal ~> 1.0.<br>
Take the example of JRuby and the bigdecimal gem for instance, it fails to <code>gem install</code>.</p>
<p>The way forward is probably to explicitly handle alternative Ruby implementations 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 the expected version of bigdecimal).</p>
<p>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 with that Ruby, and was extensively tested.<br>
Using any other version will not achieve the same level of testing, and risk incompatibilities.</p>
<p>I guess any way long term all default/bundled gems will need support for alternative implementations more explicitly, but right now it's just not the case.</p>
<p>Regarding TruffleRuby, the plan is to support default gems C extensions as much as possible, yet it might be difficult for some default gems because some of them reach very deep in the MRI implementation, more than the average gem with a C extension.</p>
<p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/286">@headius (Charles Nutter)</a> Any thoughts on this?</p> Ruby master - Bug #16951: Consistently referer dependencieshttps://bugs.ruby-lang.org/issues/16951?journal_id=861982020-06-17T08:34:28Zdeivid (David Rodríguez)
<ul></ul><blockquote>
<p>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 new Ruby version, not before, which is nice.</p>
</blockquote>
<p>This is the standard experience when your gem breaks on the newest rubies, and as you point out it's better than the alternative.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Why is this if I may ask? I tend to recall the default gems upstreams testing against several rubies according to their support range.</p>
<blockquote>
<p>Also stdlibs can have a different implementation in alternative Ruby implementations 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.</p>
</blockquote>
<blockquote>
<p>The way forward is probably to explicitly handle alternative Ruby implementations 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 the expected version of bigdecimal).</p>
</blockquote>
<p>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 implementations.</p>
<blockquote>
<p>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 with that Ruby, and was extensively tested.<br>
Using any other version will not achieve the same level of testing, and risk incompatibilities.</p>
</blockquote>
<p>I don't really buy this argument. The most stable version of a library should 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 itself.</p> Ruby master - Bug #16951: Consistently referer dependencieshttps://bugs.ruby-lang.org/issues/16951?journal_id=908122021-03-09T20:04:08Zjeremyevans0 (Jeremy Evans)merch-redmine@jeremyevans.net
<ul><li><strong>Is duplicate of</strong> <i><a class="issue tracker-1 status-5 priority-4 priority-default closed" href="/issues/14679">Bug #14679</a>: StdLib gems should properly specify their dependencies</i> added</li></ul> Ruby master - Bug #16951: Consistently referer dependencieshttps://bugs.ruby-lang.org/issues/16951?journal_id=925532021-06-17T06:15:14Zhsbt (Hiroshi SHIBATA)hsbt@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Assigned</i></li><li><strong>Assignee</strong> set to <i>hsbt (Hiroshi SHIBATA)</i></li></ul> Ruby master - Bug #16951: Consistently referer dependencieshttps://bugs.ruby-lang.org/issues/16951?journal_id=1028372023-04-17T12:18:01ZiMacTia (Mattia Giuffrida)
<ul></ul><p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/572">@hsbt (Hiroshi SHIBATA)</a> would it be possible to get an update on this? Has there been any progress over the past couple of years?</p>
<p>I'd like to share an ongoing issues that I believe is related to this: as a core maintainer of <code>faraday</code>, I'm being asked to add an explicit dependency to <code>net-http</code> in attempt to solve <a href="https://github.com/ruby/net-imap/issues/16" class="external">this issue</a>.<br>
There are currently conflicting views on what the correct course of action should be:</p>
<ol>
<li>Some, like the author of this issue, suggest gems should add an explicit dependency if they use a standard gem.</li>
<li>On the other side, I agree with <a class="user active user-mention" href="https://bugs.ruby-lang.org/users/772">@Eregon (Benoit Daloze)</a> that this will <a href="https://github.com/ruby/net-imap/issues/16#issuecomment-1511133260" class="external">only make things worse</a>, and that we should rely on Ruby loading the appropriate version of the library if this is a stdlib or standard gem.</li>
</ol>
<p>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.</p> Ruby master - Bug #16951: Consistently referer dependencieshttps://bugs.ruby-lang.org/issues/16951?journal_id=1042462023-08-23T22:10:24Zjeremyevans0 (Jeremy Evans)merch-redmine@jeremyevans.net
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Closed</i></li></ul> Ruby master - Bug #16951: Consistently referer dependencieshttps://bugs.ruby-lang.org/issues/16951?journal_id=1044402023-09-01T06:22:01Zhsbt (Hiroshi SHIBATA)hsbt@ruby-lang.org
<ul></ul><blockquote>
<p>would it be possible to get an update on this?</p>
</blockquote>
<p>It's difficult to answer. All of dependencies are maintainer's convenience basically.</p>
<p>I started to suggest to add dependency explicitly for gem authors at <a href="https://bugs.ruby-lang.org/issues/19776" class="external">https://bugs.ruby-lang.org/issues/19776</a>. You can see this suggested gems at <a href="https://github.com/ruby/ruby/blob/master/lib/bundled_gems.rb#L2" class="external">https://github.com/ruby/ruby/blob/master/lib/bundled_gems.rb#L2</a>.</p>
<p>On the other hand, I have no plan to add <code>net-http</code> into <code>Gem::BUNDLED_GEMS::SINCE</code> because <code>net-http</code> provides core feature of RubyGems. So, we can't remove it from default gems.</p>