Hello, all
After a long delay I finally pushed rspec 3.1.x into rawhide (F-22) build tree. Also I pushed rubygem-rspec2 (and so on) into rawhide tree.
So: - If your srpm already handles rspec 3.1.x, please use BuildRequires: rubygem(rspec) - Or not, you can use BuildRequires(rspec2). Note that 2.x version rspec (script) is renamed to %_bindir/rspec2, you'll probably have to do $ rspec2 spec/ for example.
Please try and test them.
Note: this change is only for F-22.
Regards, Mamoru
Dne 10.11.2014 v 14:59 Mamoru TASAKA napsal(a):
Hello, all
After a long delay I finally pushed rspec 3.1.x into rawhide (F-22) build tree. Also I pushed rubygem-rspec2 (and so on) into rawhide tree.
Thank you for the great work (and Josef for reviews)!
So:
- If your srpm already handles rspec 3.1.x, please use BuildRequires: rubygem(rspec)
- Or not, you can use BuildRequires(rspec2). Note that 2.x version rspec (script) is renamed to %_bindir/rspec2, you'll probably have to do $ rspec2 spec/ for example.
I assume you can use also:
Requires: rubygem(rspec) < 3
to get RSpec 2.x. I'm asking because that is how minitest is done ....
Please try and test them.
BTW, what is the reason for
Source1: rubygem-%{gem_name}-%{version}-full.tar.gz
Vít
Hello,Vít:
Vít Ondruch wrote on 11/10/2014 11:32 PM:
BTW, what is the reason for Source1: rubygem-%{gem_name}-%{version}-full.tar.gz
It seems that rspec series 3.x gem no longer contains spec/ directory by default. Doing %check needs it, so while I guess only adding spec/ files (from upstream git) is needed, for now I archive full source.
Vít
Regards, Mamoru
Dne 10.11.2014 v 16:49 Mamoru TASAKA napsal(a):
Hello,Vít:
Vít Ondruch wrote on 11/10/2014 11:32 PM:
BTW, what is the reason for Source1: rubygem-%{gem_name}-%{version}-full.tar.gz
It seems that rspec series 3.x gem no longer contains spec/ directory by default. Doing %check needs it, so while I guess only adding spec/ files (from upstream git) is needed, for now I archive full source.
Ah, I obviously missed the "%setup -q -D -T -n %{gem_name}-%{version} -a 1" which expands the archive, that is what confused me :) Thanks for explanation.
Vít
On Mon, Nov 10, 2014 at 7:32 AM, Vít Ondruch vondruch@redhat.com wrote:
Dne 10.11.2014 v 14:59 Mamoru TASAKA napsal(a):
Hello, all
After a long delay I finally pushed rspec 3.1.x into rawhide (F-22) build tree. Also I pushed rubygem-rspec2 (and so on) into rawhide tree.
Thank you for the great work (and Josef for reviews)!
Yes, thank you both for working on this!
- Ken
Dne 10.11.2014 v 14:59 Mamoru TASAKA napsal(a):
- Or not, you can use BuildRequires(rspec2). Note that 2.x version rspec (script) is renamed to %_bindir/rspec2, you'll probably have to do $ rspec2 spec/ for example.
Used the rspec2 command for the first time, I have strange feeling about it. Shouldn't we provide also plain rspec command for rspec2?
Let me explain. When you install RSpec 2.x and RSpec 3.x side by side by gem install, you'll get single rspec executable. You can later choose which version you actually want to execute by something like "rspec _2.2_". So while I agree that rspec2 is a bit simpler than the previous command, I'd say that the rspec command should be available as well, since when only RSpec 2.x is available on your system, it is unexpected to don't have the rspec command available, otherwise user experience is broken IMO. Thoughts? I'll probably file bug later ...
Vít
Thoughts?
I agree. There is probably no reason not to have both or?
Josef
----- Original Message ----- From: "Vít Ondruch" vondruch@redhat.com To: ruby-sig@lists.fedoraproject.org Sent: Friday, November 28, 2014 12:15:20 PM Subject: Re: rspec 3.1.x in rawhide
Dne 10.11.2014 v 14:59 Mamoru TASAKA napsal(a):
- Or not, you can use BuildRequires(rspec2). Note that 2.x version rspec (script) is renamed to %_bindir/rspec2, you'll probably have to do $ rspec2 spec/ for example.
Used the rspec2 command for the first time, I have strange feeling about it. Shouldn't we provide also plain rspec command for rspec2?
Let me explain. When you install RSpec 2.x and RSpec 3.x side by side by gem install, you'll get single rspec executable. You can later choose which version you actually want to execute by something like "rspec _2.2_". So while I agree that rspec2 is a bit simpler than the previous command, I'd say that the rspec command should be available as well, since when only RSpec 2.x is available on your system, it is unexpected to don't have the rspec command available, otherwise user experience is broken IMO. Thoughts? I'll probably file bug later ...
Vít
_______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Vít Ondruch wrote on 11/28/2014 08:15 PM:
Dne 10.11.2014 v 14:59 Mamoru TASAKA napsal(a):
- Or not, you can use BuildRequires(rspec2). Note that 2.x version rspec (script) is renamed to %_bindir/rspec2, you'll probably have to do $ rspec2 spec/ for example.
Used the rspec2 command for the first time, I have strange feeling about it. Shouldn't we provide also plain rspec command for rspec2?
Let me explain. When you install RSpec 2.x and RSpec 3.x side by side by gem install, you'll get single rspec executable. You can later choose which version you actually want to execute by something like "rspec _2.2_".
And this won't work at all when rspec2 and rspec (3) is really parallel installed:
[tasaka1@localhost rspec-expectations-2.14.5]$ rspec _2.14.8_ spec Run options: include {:focused=>true}
All examples were filtered out; ignoring {:focused=>true} FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF (very long, rest cut out)
... And so current rspec2 "command" won't work either, in this way. This is because while rspec _2.14.8_ tries to use rspec-core with that version, for rspec-expectations and rspec-mocks (used internally) this does not apply.
So the correct way is to specify core, expectations, mocks all versions to "~> 2.14.0" in /usr/bin/rspec2 (fixed in rubygem-rspec2-core-2.14.8-4.fc22), and we don't expect that rspec _2.14.8_ really works.
So while I agree that rspec2 is a bit simpler than the previous command, I'd say that the rspec command should be available as well, since when only RSpec 2.x is available on your system, it is unexpected to don't have the rspec command available, otherwise user experience is broken IMO. Thoughts? I'll probably file bug later ...
Vít
Regards, Mamoru
Dne 2.12.2014 v 13:41 Mamoru TASAKA napsal(a):
Vít Ondruch wrote on 11/28/2014 08:15 PM:
Dne 10.11.2014 v 14:59 Mamoru TASAKA napsal(a):
- Or not, you can use BuildRequires(rspec2). Note that 2.x version rspec (script) is renamed to %_bindir/rspec2, you'll probably have to do $ rspec2 spec/ for example.
Used the rspec2 command for the first time, I have strange feeling about it. Shouldn't we provide also plain rspec command for rspec2?
Let me explain. When you install RSpec 2.x and RSpec 3.x side by side by gem install, you'll get single rspec executable. You can later choose which version you actually want to execute by something like "rspec _2.2_".
And this won't work at all when rspec2 and rspec (3) is really parallel installed:
[tasaka1@localhost rspec-expectations-2.14.5]$ rspec _2.14.8_ spec Run options: include {:focused=>true}
All examples were filtered out; ignoring {:focused=>true} FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF (very long, rest cut out)
... And so current rspec2 "command" won't work either, in this way. This is because while rspec _2.14.8_ tries to use rspec-core with that version, for rspec-expectations and rspec-mocks (used internally) this does not apply.
Yes, you are right. It is because the rspec-core does not enforce the dependencies on rspec-mock and rspec-expectations, hence it can't enforce their versions ... not nice :/
So the correct way is to specify core, expectations, mocks all versions to "~> 2.14.0" in /usr/bin/rspec2 (fixed in rubygem-rspec2-core-2.14.8-4.fc22), and we don't expect that rspec _2.14.8_ really works.
It is silly that RSpec supports just precise version specification, so even your fix cannot narrow this issue :/ I opened upstream ticket [1] which could help to resolve this issue.
Vít
Dne 2.12.2014 v 15:24 Vít Ondruch napsal(a):
So the correct way is to specify core, expectations, mocks all versions to "~> 2.14.0" in /usr/bin/rspec2 (fixed in rubygem-rspec2-core-2.14.8-4.fc22), and we don't expect that rspec _2.14.8_ really works.
BTW, shouldn't you drop the line 17 [1]?
Vít
[1] http://pkgs.fedoraproject.org/cgit/rubygem-rspec2-core.git/tree/rspec2#n17
ruby-sig@lists.fedoraproject.org
-
Josef Stribny -
Ken Dreyer -
Mamoru TASAKA -
Vít Ondruch