Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Automatic Bundle installation #876

gbprz opened this Issue Feb 6, 2014 · 11 comments


None yet
5 participants

gbprz commented Feb 6, 2014

At the last meeting, of few of us mentioned issues with the Bundler auto install behavior in config/boot. I ran into the issue when working on a local concerto plugin. A few potential causes were mentioned, possibly related with the recent version update to Bundler. A quick fix is to disable automatic bundle installation in config/concerto.yml.


zr2d2 commented Feb 7, 2014

If bundle install works on the command line, then it's more likely a problem with the Concerto boot. I have yet to replicate this, but it may be loading the wrong bundler gem, or the bundler gem may not be updating according to the Gemfile restriction


yakatz commented Feb 7, 2014

I had the same problem (I think). I have all the gems installed using RVM and a unicorn configuration that works with all the rest of my rails apps, so I don't want to change it, but every time concerto starts, it forces the gems back to a vendor install so it boots properly but then does not ever restart because my unicorn can not access the gems that don't exist in the vendor directory.


zr2d2 commented Feb 7, 2014

you can alter the behavior of the automatic bundler run by editing bundle_install_options in config/concerto.yml. Since this file is version controlled, it will be overridden on version updates, but this will allow you to use Concerto with RVM. It might also help with the unicorn path resolution, though I doubt it


augustf commented Feb 7, 2014

My thought is that we should change the behavior of the automatic bundle install a bit. On boot, we should check for the preference in the bundle config file (if a user wants systemwide gems) and then act accordingly (either run with the vendor/bundle bit or not).


zr2d2 commented Feb 7, 2014

That's a related issue, but slightly different from bundler not being at the right version. It looks like there are 2 problems

  1. bundler doesn't update itself through the Gemfile; adding a requirement for it in the Gemfile has no effect on what version is installed (1.3.6 stayed installed even though >= 1.5.0 is required
  2. if the platform dependency comes before the newer bundler is installed, no gems are installed

mikldt commented Feb 8, 2014

@gabe283 and anyone else having the "Bundler::GemNotFound" issue for local gems: it looks like there were some problems with bundler 1.5.1 and 1.5.2. I installed 1.5.3 on my system (gem install bundler --version 1.5.3) and things now seem to be running smoothly.

If this seems to work for others, we should probably update the Gemfile to force this version.

I wasn't able to track down a root cause for the difference in behavior between the console and boot.rb. I /think/ I successfuly replicated boot.rb's environment and ran bundle install successfuly, but it's difficult to tell. At the end of the day the deepest into bundler as I was able to trace it was that for some reason (either parsing Gemfile, Gemfile.lock, or dependency resolution), the spec it finally tried to load for the plugin was the rubygems repository, and not the local filesystem path.

The bundler changelog for 1.5.3 indicates a few related-sounding issues.


zr2d2 commented Feb 8, 2014

The bundler version isn't actually controlled in the Gemfile, at least not in my testing. As far as I know, the version is only ever passed to the gem install command, and is ignored by bundler itself. We can check the version of bundler on boot, if we want, and provide a message of some sort, we could probably install 1.5.3 for them if we really wanted to


augustf commented Feb 12, 2014

So there's no real point in mentioning Bundler in the Gemfile? I can't replicate this issue myself, but perhaps we should have that ruby_21 symbol only for folks who have the cutting-edge bundlers.


augustf commented Feb 12, 2014

While I regard it as a bug that bundler chokes on unrecognized platform symbols, it seems to me that we can a) enclose the symbol in some logic (either checking the bundler version or just preventing the exception) so things dont crash b) remove the ruby_ 21 symbol or c) ditch Ruby 1.8 and get rid of the platforms argument entirely.


zr2d2 commented Feb 12, 2014

I think ending 1.8 support would be the cleanest code-wise, would it be a problem for people upgrading Concerto?

mikldt added a commit that referenced this issue Feb 13, 2014

Don't support platforms bundler doesn't know about
This is an alternate solution to #872 that should prevent folks from
running into #876.

@zr2d2 zr2d2 added Backend BUG labels Feb 14, 2014


zr2d2 commented Feb 14, 2014

I successfully ran bundle install in my Ubuntu VM using bundler 1.3.6

@zr2d2 zr2d2 closed this Feb 14, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment