Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

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:

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.

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 :)


Vit


Vit