Migration from RSpec 1.3 to RSpec 2.x

[Bohuslav Kabrda]

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