Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

dependency on Rails 3.1? #4

Closed
pivotal-casebook opened this Issue · 9 comments

3 participants

@pivotal-casebook

Hi -- What is the dependency on Rails 3.1? We'd like to use it with Rails 3.0. Thanks!

@deadlyicon
Owner
@pivotal-casebook

Thank you for the reply. Some of our team is in SF but most of us are in NYC. We're Pivotal Labs -- if you're in SF and involved in Ruby you might know some of our developers.

Are you using bundler? When we add your gem to our Gemfile your usage of activesupport and actionpack v.313 collides with any application not on that version fo Rails.

Feel free to reply directly if you'd like to take this conversation via email: -- joe@pivotallabs.com.

Some background: our large team is evaluating parallell test running frameworks and we're very excited about hobson, but would need to make quite a few alterations to make it viable for us, such as extensive re-run hooks, ability to filter which specs/features are executed, etc.

@deadlyicon
Owner

I've updated the README. Please let me know if there is anything confusing or left out.

@pivotal-casebook

Thanks for the update. Unfortunately there are still issues and it seems that the hobson gem is required by any project using bundler and/or rvm. specifically with Bundler and rvm.

For example:

 > cd ~/hobson && bundle install

This would install hobson into the global gemset if using rvm, which is discouraged.

In addition, when running a variation of your command:

 > cd ~/hobson_workspace && bundle exec ~/hobson/bin/hobson work # note the bundle exec

... then bin/hobson.rb:9 Bundle.setup is executed within the hobson_workspace's bundler, and thus hobson is not available.

@deadlyicon
Owner
@Peeja

checkout the first few lines of ~/hobson/bin/hobson. the hobson command
should be setup to use hobson's internal gemfile. This seemed appropriate
since hobson is more of a stand along script you use rather then a gem you
would install.

The thing is, it's still a project dependency that needs versioning. If a project only works with a particular version of Hobson, it needs to be able to specify that in its Gemfile. If a developer upgrades Hobson in the Gemfile.lock and commits the change, everyone else should get the new version. If two projects on the same machine need different versions of Hobson, Bundler should be able to sort that out.

As a gem, Hobson's Gemfile ought to just reference the gemspec, and dependencies should be managed there. Bundler (and its users) will be quite confused if you don't. (I should know: I spent an entire day trying to figure out why Hobson requiring the uuid gem was causing Bundler to complain. It was because hobson/bin/hobson forcibly resets the Gemfile location.)

@deadlyicon
Owner
@Peeja

That makes sense. I hear you that the workers run multiple projects, and therefore can't be tied to a single project's dependencies.

I wonder if the worker and the runner commands should be split. I found it a little strange that they were the same bin/hobson anyhow. Perhaps it would make sense to make a hobson-client a development dependency of your app, and run a hobson-worker on the worker machines? If there's currently code shared between those parts, that's probably a smell, and this would enforce the separation.

@deadlyicon
Owner
@deadlyicon deadlyicon closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.