jeremyevans / home_run

Fast Date/DateTime classes for ruby :: Unmaintained, unnecessary on ruby 1.9.3+
Other
465 stars 10 forks source link

Incompatible with activesupport 3 (Rails 3) #12

Closed JonRowe closed 14 years ago

JonRowe commented 14 years ago

Seems that home_run is incompatible with some of the extensions activesupport defines in 3.0 (as used by rails 3.0). See http://gist.github.com/569939 for more info.

jeremyevans commented 14 years ago

The only way I could reproduce this is if I load the stdlib date library first, then load the active support core extension, then remove the stdlib date class and use home_run's:

jeremy@ubuntu:~$ ruby -r active_support/core_ext/time/calculations -e "p [Time.now.advance(:weeks=>1), Date.today]"
[2010-09-15 08:05:09 -0700, #<Date: 2010-09-08 (4910895/2,0,2299161)>]

jeremy@ubuntu:~$ ruby -r active_support/core_ext/time/calculations -I ./home_run/lib -e "p [Time.now.advance(:weeks=>1), Date.today]"
[2010-09-15 08:05:36 -0700, #<Date 2010-09-08>]

jeremy@ubuntu:~$ home_run/bin/home_run ruby -r active_support/core_ext/time/calculations -e "p [Time.now.advance(:weeks=>1), Date.today]"
[2010-09-15 08:05:58 -0700, #<Date 2010-09-08>]

jeremy@ubuntu:~$ ruby -r active_support/core_ext/time/calculations -e" $:.unshift('./home_run/lib'); require 'home_run'; p [Time.now.advance(:weeks=>1), Date.today]"
/home/jeremy/.rvm/gems/ruby-1.9.2-p0/gems/activesupport-3.0.0/lib/active_support/core_ext/time/calculations.rb:101:in `advance': undefined method `advance' for #<Date 2010-09-08> (NoMethodError)
  from -e:1:in `<main>'

How are you loading home_run?

JonRowe commented 14 years ago

Using Bundler, so just specifying it directly, I should mention that this is on the latest version of OS X, using ruby 1.9.2, and the head of your git repository (to get round the build problem in the current release)

jeremyevans commented 14 years ago

Well, this isn't a problem with home_run itself, though it might be an issue with how Bundler loads things. If it's loading active_support before home_run, that could cause the problem. Try running the program with the bin/home_run command line tool or using bin/home_run --install to install home_run to site_packages.

The worst case scenario if it can't be fixed and you don't want to use bin/home_run and you don't want to install home_run to site_packages is you'll have to load the active_support Date core extensions manually (via load and not require).

Honestly, there's nothing that home_run can do to work around this. Please let me know if running the program with bin/home_run or installing home_run to site_packages works, as I may need to modify the README to state that it is necessary in certain cases on 1.9.

jeremyevans commented 14 years ago

Have you had a chance to test either of my suggestions from yesterday? I'd like to put out a new gem release soon and would like to know if the README changes are necessary before I release.

JonRowe commented 14 years ago

Sorry, I haven't, but I think your right in that this is down to bundler's require order. Installing to site ruby isn't really an option for me, and as bundler isolates any app from system gems have no idea if it'd even work but I shall try your bin/home_run tomorrow. Additionally I intend to try reorder the gems in the Gemfile, which I doubt will work but it's worth a try, and I am going to try requiring home_run in rails boot.rb at the same time as bundler is setup to see if that has any effect

dudleyf commented 14 years ago

Forcing a require of home_run before loading Rails works. Rails gets loaded in config/application.rb, so you can require home_run before the require 'rails/all' line there.

jeremyevans commented 14 years ago

Modify some README text (Closed by 24bc475f96ec41210fcb0df1cb63484b22cbcdaa)

In certain cases, home_run --install or home_run command is necessary on 1.9. Projects like Bundler that manipulate the load path and load things in a certain order may break when used with home_run unless you use one of the above.

Add a special note about Rails 3, in order to help some users that need to use "require 'home_run'".

JonRowe commented 14 years ago

Hate to be the bearer of more bad news, but altho this fix appears to work, anything that uses Date that is required by bundler internally (e.g. yaml) is broken even when requiring home_run before anything else.

This may be solved by installing home run as a system gem and requiring it before bundler, and then again inside bundler via the gem file (otherwise bundler will isolate it) or by installing to site_ruby and then again inside bundler (due to its isolation properties) but I cannot test this on the project I was installing home_run on.

An example of such things broken by this scenario is delayed job, which uses yaml to serialise ruby objects, home_run dates cannot be serialised properly and fail when jobs are later run.

I think bundler and home run may be incompatible for the time being :(

jeremyevans commented 14 years ago

The fully supported ways of using home run are via home_run --install and home_run command. Using "require 'home_run'" is best effort and it's not possible to make it work in all cases.

It should work with bundler if you use one of the two supported ways. If not, I'd say that it is an error in bundler, as bundler should not be mucking with the load path so much as to remove site_packages or stuff specified via RUBYOPT=-r from the load path.

bpoweski commented 13 years ago

I was able to make it work for Rails 3 + Bundler by using the following boot.rb

require 'rubygems'
require 'home_run'

# Set up gems listed in the Gemfile.
gemfile = File.expand_path('../../Gemfile', __FILE__)
begin
  ENV['BUNDLE_GEMFILE'] = gemfile
  require 'bundler'
  Bundler.setup
rescue Bundler::GemNotFound => e
  STDERR.puts e.message
  STDERR.puts "Try running `bundle install`."
  exit!
end if File.exist?(gemfile)

Then defining the Gemfile like:

gem 'home_run', :require => false