Skip to content
This repository has been archived by the owner on Sep 24, 2019. It is now read-only.

remove bundler #83

Merged
merged 18 commits into from
Nov 2, 2015
Merged

remove bundler #83

merged 18 commits into from
Nov 2, 2015

Conversation

nbargnesi
Copy link
Member

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.
    

Nick Bargnesi added 18 commits October 26, 2015 17:10
Won't be needed going forward.
- Add sudo option to run on new Travis infrastructure.
- Set BR_ISOLATE to "yes".
- Run scripts/ci.sh.
- Remove bundler requirement.
Include reference documentation URLs.
- Use BR_ prefix to discern library-specific stuff.
- Add isolation options.
- Add dependency paths.
If BR_ISOLATE is set yes, we'll manage the gem.deps.rb dependencies and
keep them isolated from any user/system gems. What this exactly means is
the following:

- The *only* requirements are ruby and gem
- We'll recreate the isolated gems anytime gem.deps.rb changes
- If gem.deps.rb *hasn't* changed, we do nothing and incur negligible
  overhead
- This supports multiple ruby environments with rbenv, rvm, chruby, and
  whatever other tools Seattle developers are using though overriding
  BR_RUBY_CMD and BR_GEM_CMD work just as well.
Gem 2.4 and older supports '--no-lock'. Older versions always generate
it it seems.
Sets env variables and add Gem.bindir to PATH if needed.
This accounts for old versions of gem.
@abargnesi
Copy link
Member

🙇

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 added a commit that referenced this pull request Nov 2, 2015
@abargnesi abargnesi merged commit 79b0e2e into OpenBEL:next Nov 2, 2015
@abargnesi
Copy link
Member

Opened #84 and #85 per my comments.

@abargnesi abargnesi mentioned this pull request Nov 17, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants