CI tests fail due to bundle install timeout
Leave a comment
See https://github.com/cowboyd/therubyracer/issues/218.
Since therubyracer already takes a long time to compile (and with the new libv8 dependency, even waaaay more), I think it might be better for Tracks to depend on a system JavaScript runtime by default, and provide therubyracer and libv8 as optional (i.e. commented-out) components for people whose systems don't already have a runtime available. That way environments like Heroku (which specifically deprecates therubyracer) and Travis (which already has Node.js available on its worker boxes) can take advantage of native support without editing the Gemfile.
Note that this wouldn't be the only instance of Tracks depending by default on native system resources -- the database gems already have system library dependencies.
Since therubyracer already takes a long time to compile (and with the new libv8 dependency, even waaaay more), I think it might be better for Tracks to depend on a system JavaScript runtime by default, and provide therubyracer and libv8 as optional (i.e. commented-out) components for people whose systems don't already have a runtime available. That way environments like Heroku (which specifically deprecates therubyracer) and Travis (which already has Node.js available on its worker boxes) can take advantage of native support without editing the Gemfile.
Note that this wouldn't be the only instance of Tracks depending by default on native system resources -- the database gems already have system library dependencies.
on 2012-12-31 03:04 *
By zoombody
Status changed from Fixed to Accepted
Status changed from Fixed to Accepted
I'm reopening this because although it's OK for the moment (only because the Travis folks seem to be following the issue and making specific allowances for it), we need to track therubyracer ticket #215 which is the root of this issue. The libv8 dependency will be changing.