Migration from RSpec 1.3 to RSpec 2.x

[Bohuslav Kabrda]

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