Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Dne 20.2.2012 13:31, Mo Morsi napsal(a):
> On 02/20/2012 07:20 AM, Vít Ondruch wrote:
>> Dne 20.2.2012 12:45, Mo Morsi napsal(a):
>>
>> 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?

Ah, sorry, you are right. I was probably confused by the "lib/rspec.rb" 
hack in rubygem-rspec-core which should be removed then. But in what 
point in time?

>
>
>>
>> 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.

Now when you made me realize that I was wrong, I think it should work, 
except the possible collision with the "lib/rspec.rb" mentioned above. I 
need to take a look into this matter once more.

>
>
> (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.

It is good time before package guidelines gets accepted I think. Anybody 
against this proposal?


Vit


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