Migration from RSpec 1.3 to RSpec 2.x

Mon Feb 27 13:43:52 UTC 2012

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

-- 
Regards,
Bohuslav "Slavek" Kabrda.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rspec.diff
Type: text/x-patch
Size: 2992 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/ruby-sig/attachments/20120227/e58e9528/attachment.bin>