Migration from RSpec 1.3 to RSpec 2.x

Mon Feb 27 14:19:26 UTC 2012

Dne 27.2.2012 14:43, Bohuslav Kabrda napsal(a):
>> ----- Original Message -----
>>> ----- Original Message -----
>>>> ----- Original Message -----
>>>>> 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
>>>> I agree that BR:/usr/bin/rspec is right - and it will also draw
>>>> in
>>>> only the necessary dependencies. As for the runtime Requires, I
>>>> believe we should stick with what's written in the gemspec (if it
>>>> is
>>>> rspec, let it be rspec, if rspec-core, then rspec-core). This
>>>> way,
>>>> we can make sure that requiring gem doesn't break with "Could not
>>>> find rspec (= 2.8) amongst [...]" - that should probably be
>>>> mentioned in the guidelines too, so that someone doesn't do
>>>> Requires: /usr/bin/rspec.
>>>> And yes, we should make an explicit note to the guidelines, that
>>>> BR:/usr/bin/rspec is the right way to do things before they get
>>>> approved (and then slowly change this when updating the packages
>>>> that depend on rubygem(rspec-core)).
>>>>
>>>> --
>>>> Regards,
>>>> Bohuslav "Slavek" Kabrda.
>>> So here is my resume :) :
>>> The /usr/bin/rspec dependency can be used most of the time, as the
>>> rspec-core gem (that contains it) draws all the dependencies
>>> (rspec-mocks, rspec-expectations) in by itself. The only thing that
>>> it doesn't contain is the rspec/rspec.rb file, which is currently
>>> created in our specfile. So, with the upstream version, everything
>>> works fine if the specs don't "require 'rspec'". I'm really not
>>> sure
>>> why there have to be rspec and rspec-core gems, since the rspec gem
>>> doesn't really do anything. I asked upstream, so let's wait what
>>> they'll respond.
>>> As a result, it is not always possible to rely on /usr/bin/rspec
>>> without having it modified the way we do.
>>>
>>> --
>>> Regards,
>>> Bohuslav "Slavek" Kabrda.
>> Yes, and the issue is at
>> https://github.com/rspec/rspec-core/issues/577.
>>
>> --
>> Regards,
>> Bohuslav "Slavek" Kabrda.
> So it seems after all, that /usr/bin/rspec is not a good idea. The explanation is given in the issue from my previous email. Basically, the rspec-core gem is meant to be able to also work with different libraries than rspec-mocks and rspec-expectations. Therefore, if you install rspec, then by default you use all the rspec stuff, and if you only install rspec-core, then it is your responsibility to provide the other libraries for it.
> So here is the proposed solution:
> In Fedora 17, we should let the rspec-core be as it is (including the added rspec/rspec.rb file), and rspec will be completely empty and just require all the other rspec stuff.
> In newer Fedoras (>  17), we should actually include the contents of rspec gem into the rpm, remove the rspec/rspec.rb from the rspec-core package and remove the dependencies on rubygem-rspec-{mocks,expectations} from rspec-core and leave them only in rspec itself. That way, from F18 we will conform with upstream completely. Also, we can use BR:rubygem(rspec) as well as R:rubygem(rspec) in F>= 17.
> I'm attaching the proposed diff of the rspec specfile, that I made and I hope to get some comments from you.
>
> Thank you for reading all this through :)
>
>
>
> _______________________________________________
> ruby-sig mailing list
> ruby-sig at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

So if I understand it correctly, the attached diff modifies the spec for 
F17 as well as for Rawhide. I like it. So if there will be no 
objections, I would like to go ahead with this change let say next 
Monday, i.e. 5th of March.

This also means that all the packages would be possible to immediately 
adjust to use rubygem(rspec) after this change.

Finally, the dependencies and the additional lib/rpsec.rb file would be 
removed from rubygem-rspec-core for F18 after F17 is declared gold, i.e. 
second half of May. This would leave us some time to keep focus on 
R1.9.3 issues before rebuild needed due the RSpec changes.

Vit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/ruby-sig/attachments/20120227/8dd844b6/attachment-0001.html>