I have a new icalendar Ruby library/gem which is implemented so as
require an implementation of the TZInfo::Timezone class, but not to
care whether that implementation comes from the tzinfo gem, or the
activesupport gem in rails. It also will make use of the TimeWithZone
class in recent versions of activesupport if it’s loaded, but it
leaves the decision of whether to load the activesuport or tzinfo gems
up to the user.
Now, it that makes sense I’d like to be able to run my specs with the
tzinfo gen and then with the activesupport gem. Ideally I’d like to
have rake tasks like
rake spec:tzinfo
rake spec:activesupport
rake spec:both
The problem is that I think I need something like the fork option for
spec task similar to the one in the cucumber task, since once loaded I
can’t unload one or the other gem in the same ruby process.
Is there a trick I’m missing?
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
On Fri, May 15, 2009 at 11:50 AM, Rick DeNatale
[email protected] wrote:
have rake tasks like
rake spec:tzinfo
rake spec:activesupport
rake spec:both
The problem is that I think I need something like the fork option for
spec task similar to the one in the cucumber task, since once loaded I
can’t unload one or the other gem in the same ruby process.
Is there a trick I’m missing?
Sounds like a missing feature, actually. RSpec’s own suite has a
forker, which I’m pretty sure that Aslak wrote and is likely the
source of the cucumber option you’re talking about, but it is not
exposed as an API, yet. I think it should be. Wanna patch it?
On Sat, May 16, 2009 at 11:57 AM, David C. [email protected]
wrote:
can’t unload one or the other gem in the same ruby process.
Is there a trick I’m missing?
Sounds like a missing feature, actually. RSpec’s own suite has a
forker, which I’m pretty sure that Aslak wrote and is likely the
source of the cucumber option you’re talking about, but it is not
exposed as an API, yet. I think it should be. Wanna patch it?
Well, I looked it, and it seems that the RSpec spectask does in fact
run rspec in a separate process using the system command.
So I tried to make a spectask to run the specs after require in
activesupport by adding this in my rake file:
desc “Run all specs with activesupport”
Spec::Rake::SpecTask.new(:spec_as) do |t|
t.spec_opts = [‘–options’, “spec/spec.opts”]
t.ruby_opts = [‘-rrubygems’, ‘-ractive_support’]
t.spec_files = FileList[‘spec/**/*_spec.rb’]
t.verbose = true
end
Unfortunately, it seems that the ruby command only handles a single -r
option, the -rrubygems gets ignored and things fail because it can’t
find active_support.rb, the same thing happens if I just try:
$ruby -rrubygems -ractive_support -e’puts “Hello”’
Right now the only approach I can think of is to somehow set an
environment variable which my spec helper would look at to determine
whether to require activesupport, but I don’t even know if that’s
possible with Kernel#system particularly in a platform independent
way.
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
On Sun, May 17, 2009 at 9:46 AM, Rick DeNatale [email protected]
wrote:
way.
Follow up. I figured it out. The problem wasn’t that Ruby doesn’t
allow multiple -r options, it was that the way it’s done -rubygems
-rsomegem won’t work since -r doesn’t use the same mechanism as
require so that rubygems doesn’t get involved.
I fixed it by having an auxiliary .rb files which require rubygems and
either activesupport or tzinfo and -r requiring that.
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale