remove bundler

[nbargnesi]

Proposed fix for #82; summary:

1. Uses the upgraded Travis CI infrastructure.

   With gems entirely isolated from the existing user and system set, we never need sudo access.

2. Isolation

   When isolation is used, gems will be located at the base of the repository at .gems. This keeps the entire developer experience simple. Everything is in one spot. See BR_ISOLATE for more.

3. Multiple Rubies

   Multiple versions of Ruby are more straightforward. Ruby switchers will continued to work, but for developer and production environments with multiple Ruby installations coexisting, changing BR_RUBY_CMD and BR_GEM_CMD will allow isolated tests under whatever versions are configured.

4. Updating dependencies will trigger the isolated environment to be recreated.

   This makes it dead simple to experiment with different gems and/or versions. When the dependencies change, the isolated gems will be refreshed.

   Dependencies updated, removing old isolation path... okay
   

5. Existing isolated environments continue to work when dependencies remain the same.

   Existing isolation path up-to-date.
   

[abargnesi]

🙇

I have reviewed this by pulling in the your issue82 branch and testing out a few things:

Without dependencies can I run, in a meaningful way...

• irb
• pry
• executables in bin/
• rake tasks

Of course these all failed with LoadError.

Then I went looking to install gem dependencies.

1. Use bundler ( 😄 )

I could execute bundle install --gemfile gem.deps.rb and then use BUNDLE_GEMFILE=gem.deps.rb bundle exec to execute with gem dependencies set on the $LOAD_PATH. The solution seemed disconnected to me and against the nature of the PR.

1. Use rubygems

I used gem install -g gem.deps.rb --no-user-install --install-dir gems --development to install the dependencies locally (what seems to be called isolate) and then execute with GEM_HOME=gems GEM_PATH=gems .... You can also use RUBYGEMS_GEMDEPS=gem.deps.rb env variable to setup the $LOAD_PATH but it wasn't strictly necessary since rubygems will handle this for you at runtime.

The solution in (2) was more appealing since it leveraged core ruby utilities and seems more intuitive.

---

I haven't tried the scripts yet, but can only imagine it gives you a nicer interface to the command.

All in all it looks fantastic. I do have some follow-ups:

• We should add a rationale section in the README around the approach of gem dependencies and isolation. Although this is a friendlier approach it may not be familiar to Ruby developers. This is coming from a stance of inclusivity for those folks.
• The awesome script interface is great for Unix folks, but we have a number of interested Windows users. We should indicate the requirements needed for scripting support to include those folks.
• We should add testing functionality to the gosh interface. My rationale here is that a test script can serve as an overall abstraction and be really obvious what it does (vs. rspec ...).

[abargnesi]

Opened #84 and #85 per my comments.