Dne 10. 01. 20 v 18:24 Jun Aruga napsal(a):
>>> Perhaps, this time, may we be able to wait for the new release Ruby
>>> 2.7.1 to release Ruby 2.7 on Fedora?
>>> How do you think?
>> Hello,
>>
>> Please correct me if I'm wrong but the enhancements are adding functionality 
>> (feature?) to be used when you need to handle the flag for `ruby2_keywords` 
>> explicitly (https://bugs.ruby-lang.org/issues/16486).
> In my understanding. the referred note says there is a problem about
> the way for Ruby to make users to implement ruby2_keywords to suppress
> the mixed positional and keyword argument's warnings on Ruby 2.7.0.
>
> It's not a new enhancement, but a deprecation for a case that is a
> method with the mixed positional and keyword argument and the
> delegation.
> Because in Ruby 3.0, they want to be a syntax error for this pattern.
>
> For example, try to run following code on both Ruby 2.7.0 and Ruby 2.6
>
> ## Case A
>
> ```
> def target(*args, **kwargs)
>   [args, kwargs]
> end
>
> def delegate(*args, &block)
>   target(*args, &block)
> end
>
> delegate(1, b: 2)
> ```
>
> On Ruby 2.6, the delegate method works.
>
> ```
> delegate(1, b: 2) => [[1], {:b=>2}]
> ```
>
> On Ruby 2.7.0, it shows deprecation message.
>
> ```
> delegate(1, b: 2)
> (irb):5: warning: Using the last argument as keyword parameters is
> deprecated; maybe ** should be added to the call
> (irb):1: warning: The called method `target' is defined here
> => [[1], {:b=>2}]
> ```
>
> The problem is how to fix the deprecation message considering both
> Ruby 2.7.0 and old Rubies.
> They are recommending to use "ruby2_keywords" that is internally
> implemented in Ruby 2.7.0.
>
> ## Case B
>
> ```
> def target(*args, **kwargs)
>   [args, kwargs]
> end
>
> ruby2_keywords def delegate(*args, &block)
>   target(*args, &block)
> end
>
> delegate(1, b: 2)
> ```
>
> So, this code works on Ruby 2.7.0.
>
> ```
> delegate(1, b: 2) => [[1], {:b=>2}]
> ```
>
> But "ruby2_keywords" is not implemented in Ruby 2.6.
> Users need to install "ruby2_keywords" to run a Ruby program on older Rubies,
> and need to add "require 'ruby2_keywords' to the code for the older Rubies.
>
> Gemfile
>
> ```
> gem 'ruby2_keywords'
> ```
>
> The above suggestion (= note-12) says that Ruby 2.7.1 should work on
> the above case A without deprecation message.
> https://bugs.ruby-lang.org/issues/16454#note-12
>
> So, I have 2 concerns for this situation.
>
> * 1. For example we will release Ruby 2.7.0 and doing mass build.
>   Then we will contribute upstream to add "ruby2_keywords" to the
> candidates methods.
>   But the modification might not be needed anymore again in Ruby 2.7.0.
> * 2. Fedora users using Fedora Ruby might have to fix their Ruby code
> for only Ruby 2.7.0.
>
>
> ## Case C
>
> ```
> def target(*args)
>   [args]
> end
>
> def delegate(*args, &block)
>   target(*args, &block)
> end
>
> delegate(1, {b: 2})
> ```
>
> ```
> delegate(1, {b: 2}) => [[1], {:b=>2}]
> ```
>
> But writing this email, I got an idea. When we contribute the upstream
> (such as sending pull-request) to modify Case A to Case C without
> using ruby2_keywords,
> it solves the above concern 1.
>
>> So either way the current code (packaged gems) needs to be fixed to work 
>> with 2.7 (and yes, we'll probably get better debugging, but gems' upstream 
>> is the place to fix those issues; not Fedora).
> We might need to patch it for only Ruby 2.7.0 on Fedora.
>
>> I expect 2.7.1 to hit Rawhide before branching (it'll be soon, right?), so 
>> there should be no difference having a 2.7.0 build (esp. in a side-tag) now.
> The Ruby 2.7.1 release date is not clear.
> At least the next Ruby dev meeting is 16th January.
> https://bugs.ruby-lang.org/issues/16454#note-12


IMHO, it probably makes sense to wait for the dev meeting. If the change
is accepted, we can include the patch into Ruby 2.7.0 (of course, ti
might be accepted earlier, who knows).

OTOH, the mass rebuild should start on 22nd, which is quite early (and
it take 20 days?!?). May be we should give it a shot. See what happens
and possibly include the patch earlier.


Vít
_______________________________________________
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org

Reply via email to