Hi Folks,
I think I need to understand this fundamental architectural question. I
don’t know if it is a Ruby question or a Rails question, or a Ruby on
Rails
question.
Clearly I have multiple versions. Clearly I am supposed to have multiple
versions. Clearly there is an accommodation for multiple versions.
Clearly
I don’t understand how this accommodation works.
Apparently, there are the “system” gems, and there are “bundle” gems,
which
are apparently controlled by my application. Presumable my application
is
always going to want to run in the context of the assembled gems
collected
for the purposes of the application. So, my first question is, how is
this
accomplished? Simple path search order?
For whatever reason, different versions are being selected in different
contexts. I don’t know enough about how Ruby or Rails does things to
understand this, but I have a simple example:
$ rake time:zones:local
rake aborted!
You have already activated rake 10.0.4, but your Gemfile requires rake
10.3.2. Prepending bundle exec to your command may solve this.
/var/www/vhost/todo.tryx.org/tracks/config/boot.rb:6:in <top (required)>' /var/www/vhost/todo.tryx.org/tracks/config/application.rb:1:in<top
(required)>’
/var/www/vhost/todo.tryx.org/tracks/Rakefile:5:in `<top (required)>’
(See full trace by running task with --trace)
$ bundle exec rake time:zones:local
- UTC -08:00 *
Pacific Time (US & Canada)
Tijuana
Isn’t there some way to declare that the bundle context should be the
default? In my case, I am running the Ruby on Rails application through
Passenger, so I need to declare, “Use the bundle context” as the
default. If
somebody could point me in the direction of a manual that explains why
all
this works the way it does, I’d be appreciative.
Thanks for the help,
Chris.
On Tuesday, January 6, 2015 4:52:34 PM UTC, Chris M. wrote:
Apparently, there are the “system” gems, and there are “bundle” gems,
which are apparently controlled by my application. Presumable my
application is always going to want to run in the context of the assembled
gems collected for the purposes of the application. So, my first question
is, how is this accomplished? Simple path search order?
bundler makes sure only the gems (and the specific versions) listed in
Gemfile.lock are loaded which avoids all sorts of dependency based
problems. However if you just run rake, then the most recent version
of
rake is run. A few milliseconds boot.rb loads bundler, and if bundler
finds
that gems have been loaded that don’t match the version bundler wants
to
use then it aborts (since one a gem has been loaded you can’t unload it
and
load a different version)
When you run something with bundle exec, it ensures that only the gem
versions in your Gemfile.lock are specified.
You can use http://mpapis.github.io/rubygems-bundler/ which ensures that
the executables installed for rake etc. load bundler first. You can also
use the bin stubs in your app’s bin folder .
I seem to recall the passenger knows to load bundler if a Gemfile is
present - i don’t recall ever having to do something specific for this.
Fred
Hi Fred,
On Tuesday, January 6, 2015 9:06:25 AM UTC-8, Frederick C. wrote:
versions in your Gemfile.lock are specified.
You can use http://mpapis.github.io/rubygems-bundler/ which ensures that
the executables installed for rake etc. load bundler first. You can also
use the bin stubs in your app’s bin folder .
Thanks very much for the explanation. Quite clear and now I think I
understand to a much higher degree.
I seem to recall the passenger knows to load bundler if a Gemfile is
present - i don’t recall ever having to do something specific for this.
Your recollections agree with other sources, so there is something
mysterious on my machine, and I’m willing to blame SELinux. I should
have
dropped SELinux and tested, but it didn’t occur to me until I had
already
solved my problem by "gem install"ing the same version of rake and rack
that the bundle had, thereby obviating the version problem – in this
case.
Thanks for the help,
Chris.