dependency on Rails 3.1?

[pivotal-casebook]

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

[jaredatron]

I need to update Hobson's documentation. Especially for setup. I've been
meaning to do a quick screencast. I'll hopefully get to that soon.

To answer your question. Hobson shouldn't be included in your app. It runs
entirely external from your app so there should be no gem conflicts. Is be
more then happy to personally help you get Hobson setup. Are you in SF?

Jared

On Friday, February 17, 2012, Pivotal Casebook wrote:

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

---

Reply to this email directly or view it on GitHub:
#4

Jared

[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.

[jaredatron]

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.

[jaredatron]

Hey,

this is what we're doing here and it works well for us

cd ~/hobson && bundle install --path=.gems --binstubs=.bin

RE your troubles with the following command

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

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. I would love to explore more flexible approaches.

If you let me know what about this command doesn't work for you (note the
lack of bundle exec)

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

I'd be more then happy to attempt to address them asap.

=)

On Tue, Feb 21, 2012 at 2:50 PM, Pivotal Casebook <
reply@reply.github.com

wrote:

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.

---

Reply to this email directly or view it on GitHub:
#4 (comment)

Jared

[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.)

[jaredatron]

Peter,

While I can see why you would want to tie your project to a particular
version of Hobson, at the moment, the downsides of adding Hobson to your
project's Gemfile, in my opinion, out weigh the gains of version locking.
For two reasons:

1. Hobson is designed to run multiple projects. This means resolving the
   compatible set of gem versions across Hobson and more then one project is
   all but impossible. At least I can't think of how or when you would do it.

2. Adding Hobson to project Gemfiles limits the gem versions Hobson and
   your project have available to them. This in turn limits the number of
   projects Hobson is capable of running for no real gain.

Furthermore I dont, at the moment, see the gain of tying your project to a
particular version of Hobson. If you did this and your projects were linked
to different version of Hobson you woud have to setup multiple clusters of
test runners. Again for no real gain.

Hobson is fairly simple with regards to how it integrates with projects. It
really just needs to know about rspec and cucumber. So it should work for
any project running known test suite types.

In the long run it might not be best for Hobson to be a Gem. At least not
in the canonical sense. Right now its a cli, linux service and web app. It
designed to be entirely external to your app. Your app should as concerned
with the Hobson version as much as it is concerned with the version of
jenkins you're using. Not.

That all being said if you have ideas of how to restructure Hobson to make
versioning make sense I would love to discuss them with you.

I hope my answer was clear and not discouraging. I'm confident Hobson can
work for you and I hope I can continue to help you take advantage of it.

Thanks again

Jared

On Wed, Feb 22, 2012 at 10:04 AM, Peter Jaros <
reply@reply.github.com

wrote:

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.)

---

Reply to this email directly or view it on GitHub:
#4 (comment)

Jared

[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.

[jaredatron]

Peter,

I originally had the test commands that were run split out from hobson and
I would love to move back in that direction. Right now they are owned by
Hobson because Hobson needs to run rspec and cucumber with a customer
formatter. It uses this formatter to output the when each test is started,
completed and its result to a file. Hobson then reads from this file to get
realtime updates about the status of tests instead of having to wait until
the command completes to get all that info.

I like the idea of evolving towards having a hobson-server and
hobson-client so the client can be in the project gemfile. Nice!

=)

On Wed, Feb 22, 2012 at 2:45 PM, jared grippe jared@deadlyicon.com wrote:

Peter,

I originally had the test commands that were run split out from hobson and
I would love to move back in that direction. Right now they are owned by
Hobson because Hobson needs to run rspec and cucumber with a customer
formatter way hobson knows when a test is done is by including a custom
formatter into cucumber and rspec and then watching the outfile that
formatter writes to. Thats how it gets realtime updates about the status of
tests instead of having to wait until the command completes.

I like the idea of evolving towards having a hobson-server and
hobson-client so the client can be in the project gemfile. Nice!

=)

On Wed, Feb 22, 2012 at 11:42 AM, Peter Jaros <
reply@reply.github.com

wrote:

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.

---

Reply to this email directly or view it on GitHub:
#4 (comment)

Jared

Jared