Migration from RSpec 1.3 to RSpec 2.x

Mon Feb 20 12:31:20 UTC 2012

On 02/20/2012 07:20 AM, Vít Ondruch wrote:
> Dne 20.2.2012 12:45, Mo Morsi napsal(a):
>> On 02/20/2012 04:33 AM, Vít Ondruch wrote:
>>> Dne 13.2.2012 20:40, Mo Morsi napsal(a):
>>>> On 01/25/2012 04:46 AM, Vít Ondruch wrote:
>>>>> Hi guys,
>>>>>
>>>>> It seems that we have almost eliminated usage of RSpec 1.x:
>>>>>
>>>>> $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
>>>>> 'rubygem(rspec)'
>>>>> rubygem-ffi-0:1.0.9-2.fc16.src
>>>>> rubygem-linode-0:0.6.2-1.fc15.src
>>>>>
>>>>> $ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
>>>>> aeolus-conductor-devel-0:0.4.0-2.fc17.noarch
>>>>>
>>>>> $ repoquery --repoid=rawhide-source --arch=src --whatrequires 
>>>>> rubygem-rspec
>>>>> rubygem-daemon_controller-0:0.2.6-2.fc17.src
>>>>>
>>>>> $ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec
>>>>>
>>>>>
>>>>> The only remaining packages are:
>>>>> rubygem-ffi (bkearney) - seems to be just packaging bug: 
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=760009
>>>>> rubygem-linode (stahnma) - upstream is already RSpec 2.x 
>>>>> compatible, it is FTBFS currently and it would deserve update anyway
>>>>> aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are 
>>>>> rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
>>>>> rubygem-daemon_controller (pwu) - It seems there should not be 
>>>>> issue running with RSpec 2.x, although I did not tested it.
>>>>>
>>>>>
>>>>> Could we move forward and let the rubygem-rspec to follow the 
>>>>> upstream RSpec version and Require: rubygem(rspec-core)?
>>>>>
>>>>
>>>>
>>>> +1, lets move forward with this. I'm in the process of updating the 
>>>> aeolus-conductor codebase to work against ruby 1.9.3 and will look 
>>>> into incorporating an update to rspec 2 into this.
>>>>
>>>> Since linode, ffi, and daemon_controller have been taken care of 
>>>> and we've long announced the update to rspec2 in F17, lets perform 
>>>> the final cutover. If there are issues going forward, we can easily 
>>>> introduce a rspec1 compat package.
>>>>
>>>>   -Mo
>>>>
>>>
>>> Mo,
>>>
>>> You mentioned in the packaging discussion that you have prepared 
>>> patches for rubygem-rspec to migrate them to RSpec 2.x, is that 
>>> right? Could you share them with us?
>>>
>>> Vit
>>>
>>> _______________________________________________
>>> ruby-sig mailing list
>>> ruby-sig at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>>
>> Attached. All the packages which depend on rspec 1 have been taken 
>> care of except for rubygem-linode and aeolus-conductor (still in 
>> progress but should be finished soon).
>>
>> Patch updates the package to ruby 1.9 and removes the majority of the 
>> contents, adding the dependencies on the 
>> rspec-{core|mock|expectations}, bringing it inline w/ the upstream gem.
>>
>>   -Mo
>
> Thank you. Unfortunately you do not solve how to migrate from BR: 
> rubygem(rspec-core) back to BR: rubygem(rspec). The main issue is that 
> rubygem-rspec-core was patched to carry rspec executable, where now it 
> should be moved where it belongs, i.e. into rubygem-rspec. There are 
> several ways:

Huh? In the upstream gem, the 'rspec' executable is provided by 
rspec-core [1]. The upstream rspec gem [2] is merely a metapackage for 
the three rspec subpackages (core, mock, expectations), and I'm not 
seeing the aforementioned patch in the rubygem-rspec-core spec file [3] 
(the 'rspec' binary is just pulled in from the upstream gem). Why would 
we want to deviate from this?

>
> 1) We can let temporarily rubygem-rspec provide also the 
> rubygem(rspec-core), where rubygem-rspec-core would not provide any 
> rubygem() macro. This is ugly and against guidelines.
>
> 2) Temporarily make rubygem-rspec-core dependent on  rubygem(rspec), 
> which is circular dependency.
>
> Both of these workarounds would be removed for Fedora >= 18, but all 
> the gems which uses rubygem(rspec-core) needs to be rebuild. We can 
> also fake the rubygem-rspec (e.g. there would be nothing else than R: 
> rubygem(rspec-core), so new/updated packages could be fixed) and do it 
> properly for F18, including rebuild of packages.

Wouldn't it just work (tm) and be standards compliant w/ my patch as it 
is? If so why don't we go w/ the simplest route for the time being and 
then can massage it / tighten it up when the ruby-sig workload lightens up.

(though one thing I just realized that's missing from the patch is 
explicit version requirements on the rspec subpackages, can quickly fix 
that before pushing)

>
> Also, if the test suite is executed using rspec command, we should 
> think if the guidelines should not recommend usage of BR: 
> /usr/bin/rspec instead of rubygem(rspec{,-core}). The reasoning is 
> that if we run the spec using rspec command, we really care just if 
> the rspec command is available, whoever it provides. We don't care 
> whether it is provided by rubygem-rspec or rubygem-rspec-core. In 
> contrary, if the spec suite is for some reason executed just using 
> ruby, e.g. "ruby spec/my_spec.rb", in this case it should be enough to 
> require rubygem(rspec-core) and the rspec executable would never be 
> installed, since it is not needed.
>
> Sad that I did not realized this when I had done review for mtasaka. 
> Yeah, hard way to learn something :)

Ah ya this is a good idea. No worries, we can adjust it at somepoint 
going forward.

   -Mo

[1] http://rubygems.org/downloads/rspec-core-2.8.0.gem
[2] http://rubygems.org/downloads/rspec-2.8.0.gem
[3] http://pkgs.fedoraproject.org/gitweb/?p=rubygem-rspec-core.git