Ruby Issue Tracking System: Issueshttps://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112020-04-29T23:10:34ZRuby Issue Tracking System
Redmine Ruby master - Feature #16821 (Third Party's Issue): gem version notation for "rational version" c...https://bugs.ruby-lang.org/issues/168212020-04-29T23:10:34Zcolindkelley (Colin Kelley)colin@invoca.com
<p>When a gemspec wants to express a version requirement, we typically use the <code>'~> '</code> notation like this:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"> <span class="n">spec</span><span class="p">.</span><span class="nf">add_dependency</span> <span class="s1">'nokogiri'</span><span class="p">,</span> <span class="s1">'~> 1.8'</span>
</code></pre>
<p>This indicates compatibility following the "rational versioning" as described here: <a href="https://github.com/ruby/ruby/blob/master/lib/rubygems/version.rb#L72" class="external">https://github.com/ruby/ruby/blob/master/lib/rubygems/version.rb#L72</a><br>
(basically the same as Semantic Versioning: <a href="https://semver.org/" class="external">https://semver.org/</a>).</p>
<p>Anything >= 1.8 and < 2.0 is compatible.</p>
<p>But suppose a CVE comes out like this one: <a href="https://github.com/sparklemotion/nokogiri/issues/1915" class="external">https://github.com/sparklemotion/nokogiri/issues/1915</a><br>
Many developers reacted to that CVE by changing the requirement to:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"> <span class="n">spec</span><span class="p">.</span><span class="nf">add_dependency</span> <span class="s1">'nokogiri'</span><span class="p">,</span> <span class="s1">'~> 1.10.4'</span>
</code></pre>
<p>But that isn't correct, as it precludes an upgrade to 1.11. We need a notation that means >= 1.10.4 and < 2.0.</p>
<p>The only way to do that currently is to use a combination of two requirements:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"> <span class="n">spec</span><span class="p">.</span><span class="nf">add_dependency</span> <span class="s1">'nokogiri'</span><span class="p">,</span> <span class="s1">'>= 1.10.4'</span><span class="p">,</span> <span class="s1">'< 2.0'</span>
</code></pre>
<p>I propose we add a "rational compatible" option that would do the above. We could choose any prefix to mean that. For example, <code>'=>'</code>. Then the CVE requirement could be expressed succinctly:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"> <span class="n">spec</span><span class="p">.</span><span class="nf">add_dependency</span> <span class="s1">'nokogiri'</span><span class="p">,</span> <span class="s1">'=> 1.10.4'</span>
</code></pre>
<p>And developers could use this "rational compatible" operator as their default for all gem requirements.</p>
<p>The implementation would involve adding one entry to the <code>OPS</code> hash in requirement.rb:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"> <span class="s2">"=>"</span> <span class="o">=></span> <span class="nb">lambda</span> <span class="p">{</span> <span class="o">|</span><span class="n">v</span><span class="p">,</span> <span class="n">r</span><span class="o">|</span> <span class="n">v</span> <span class="o">>=</span> <span class="n">r</span> <span class="o">&&</span> <span class="n">v</span><span class="p">.</span><span class="nf">_segments</span><span class="p">.</span><span class="nf">first</span> <span class="o"><</span> <span class="p">(</span><span class="n">r</span><span class="p">.</span><span class="nf">_segments</span><span class="p">.</span><span class="nf">first</span><span class="p">.</span><span class="nf">to_i</span> <span class="o">+</span> <span class="mi">1</span><span class="p">)</span> <span class="p">}</span>
</code></pre>
<p>Please LMK if there's interest. I would be happy to submit a Pull Request including tests and documentation.</p> Ruby master - Bug #11762 (Closed): Array#dig can raise TypeError: no implicit conversion of Symbo...https://bugs.ruby-lang.org/issues/117622015-12-02T07:38:49Zcolindkelley (Colin Kelley)colin@invoca.com
<p>If you try to <code>dig</code> in an Array using a symbol or string, a <code>TypeError</code> exception will be raised:</p>
<p>irb> ['zero', 'one', 'two'].dig(:first)<br>
TypeError: no implicit conversion of Symbol into Integer<br>
from (irb):1:in `dig'<br>
from (irb):1</p>
<p>I think it should return <code>nil</code> in this case. The most typical use case for <code>dig</code> is to dig through parsed JSON and either find the result we expected or else <code>nil</code>. Wouldn't it defeat the purpose of <code>dig</code> if we had to wrap calls to it in a <code>rescue</code> to handle the case that an Array was present where we expected a Hash?</p>
<p>Can we clarify the desired behavior for this case, then update the documentation and tests to reflect that?</p> Ruby master - Feature #9278 (Closed): Magic comment "immutable: string" makes "literal".freeze th...https://bugs.ruby-lang.org/issues/92782013-12-22T09:19:45Zcolindkelley (Colin Kelley)colin@invoca.com
<p>Building on <a href="https://bugs.ruby-lang.org/issues/9042" class="external">https://bugs.ruby-lang.org/issues/9042</a>, this pull request adds the magic comment # -<em>- immutable: string -</em>- that implies .freeze on every string literal in the file. To get a mutable string in a file that starts with the magic comment, use String.new or ''.dup.</p>
<p>Here is a corresponding github pull request:</p>
<pre><code>https://github.com/ruby/ruby/pull/487
</code></pre>
<p>For more details, background, and rationale, please see this blog post:</p>
<pre><code>http://development.invoca.com/magic-comment-immutable-string-makes-ruby-2-1s-literal-freeze-optimization-the-default/
</code></pre>