I'm trying to use config/environment.rb to install a ruby gem dependency (because I don't have sudo access to our server; ergo, can't just call gem install hpricot).
I've tried including sundry arguments (:version, :source, :lib) but I still get rake aborted! no such file to load -- hpricot
Update: It turns out that when I remove the plugin which requires hpricot, then I can execute rake gems:install successfully. But that's not very helpful. It means that if I ever move my app, I run into a problem of being unable to rake its gems (because I will have reinstalled the plugin and added features that depend on it).
How is this supposed to work?
Sys: WinXP, Ruby 1.8.7, Rails 2.3.5
Rails is trying to load the gem before executing the rake task. This is a known issue with rails 2.x. The only solution I know of is to switch to using bundler to manage gems or manage then manually.
Bundler can be used with rails 2 but it requires some modifications to your application and deployment scripts. This is a good place to start: http://gembundler.com/rails23.html
rake gems:install has been deprecated because it never really worked. You can imagine having a gem installer with dependencies to the very gems it's trying to install is a bad idea.
It's advisable to use bundler instead if that's an option.
Bundler allows you to install gems to any destination you want, something specifically intended to side-step the whole "requires sudo" problem you describe. It's often as easy as this:
bundle install --path ~/my_gems/
You can make your Rails 2.3.x application use Bundler by following a few simple steps and from there your life will be a lot easier.
Related
I thought I understood how Bundler works with gems, but after something that recently happened, I am not sure I have it right.
I am developing an Rails application. To start off (and just so I would get familiar with the Rails environment which I haven't worked in before), I did not use an IDE. But, because I'm missing out on some of the advantages of an IDE, I just started using RubyMine. As part of the RubyMine setup, it asked to update all my gems for my existing project.
After that, I could not run "rake [anything]". Every time I did, I received an error of:
You have already activated rake 0.9.3.beta.1, but your Gemfile
requires rake 0.9.2.2. Using bundle exec may solve this.
I was okay updating to the next version of rake - that wasn't a problem - but I don't understand what happened in the first place. What happened that I "activated" a newer version of rake. Ultimately, I ended up solving the problem by putting
gem 'rake', '0.9.3.beta.1'
in my Gemfile and running
bundle update rake
But, I'm still not sure what happened here. If I was using 9.2.2 before, why did it all of a sudden blow up like that and how can I prevent that in the future?
If you are using Rubymine, you should configure it to run rake tasks with bundle exec.
Go to:
Run -> Edit Configurations -> Defaults -> Rake -> Bundler tab and check "Run the script in context of the bundle (bundle exec)"
Delete all tasks already created and the default will apply the next time you create them again. You can also configure individually each task created.
You should really consider installing and using RVM or Rbenv to manage your ruby versions and gemsets. If you go the Rbenv way, the rbenv-gemset plugin can be used to manage gemsets similar to how RVM natively does.
You have already activated rake 0.9.3.beta.1, but your Gemfile requires rake 0.9.2.2. Using bundle exec may solve this.
At some point between your last bundle execution and installing/configuring/running RubyMine you must have installed rake 0.9.3.beta.1. Because you're not managing your gems through gemsets like RVM or Rbenv will do for you, the default version of Rake became 0.9.3.beta.1 instead of the version installed by bundler, 0.9.2.2.
The above error suggests your Gemfile had something like
gem 'rake', '0.9.2.2'
which does not allow the version of rake being used to be anything but 0.9.2.2.
If you do in fact have 0.9.2.2 on your system in addition to the 0.9.3.beta.1 and your Gemfile is configured for 0.9.2.2, instead of running
rake some:task
you can run
bundle exec rake some:task
and bundler will run some:task through the 0.9.2.2 version of rake. Running tasks related to gems found in a Gemfile through bundleer with bundle exec ... is considered good practice regardless of using RVM or Rbenv.
You can read about bundle exec here.
After a long overdue reading of the bunder documents, I pretty much understand why it's a great thing compared to manual gem install.
But this came to me (and others) only recently, and now we have a hybrid environment. Our development machines are mostly fine. But when we deploy to production, Bundler tells capistrano to put the gems in shared/bundle/gems, which makes sense. But we still have manually installed gems in the normal .rvm location.
So now we know not to use "gem install" on production, but we're dealing with version mismatches when we run Rake tasks directly. We can use "bundle exec rake foo:bar" to force the correct behavior, I think. But for now we have a bunch of outdated gems:
Outdated gems installed by Bundler, and
Gems we manually installed using gem install
I would like to get things pristine. Is there any reason I shouldn't use gem cleanup?
Hope this isn't too convoluted :-)
Thanks in advance.
gem cleanup will keep the latest version of all gems, and remove older versions. What I think you want is this:
(Optional) create an RVM gemset for your project. (I like to do this; some people rely entirely on Bundler, which also works.)
Make sure all your top-level dependencies are specified in your Gemfile.
Remove all gems (rvm gemset empty may be helpful) except Bundler.
bundle install
Run everything with bundle exec from now on.
Since I am new to rails and have learned the very basics from books I now figured that I can learn quite a bit more from reading other peoples code and trying to make sense of it so I have signed up at github and set up everything there. Now I read that one good open source project to learn from is radiant so I went to https://github.com/radiant/radiant and cloned it to a local directory. THen I proceeded as follows:
cd radiant
bundle install, which went fine
rake db:migrate, which first returned:
rake aborted! You have already activated rake 0.9.2, but your Gemfile requires rake 0.8.7. Using bundle exec may sol
So I typed in bundle exec rake db:migrate and recieved the following:
NOTE: Gem.source_index is deprecated, use specification. It will be removed on or after 2011-11-01. Gem.source_index called from c:/Ruby192/lib/ruby/gems/1.9.1/gems/rails-2.3.14/lib/rails/gem_dependency Rake aborted! No such file to load -- radius
So here I am wondering how to fix this problem? I also noticed that a Gemfile and a Gemfile.lock already existed in the radiant folder when it was cloned, which perhaps could be part of the problem?
Also I wonder if it is crutial that I run the same version of rails as the project is written in?
Now it should be said that I currently have rails 3.0.5 installed and run on windows
I hope someone can help me here, it has been quite frustrating since I have not been able to run any cloned github repos (radiant here just being one example).
You should edit your Gemfile and make it require newer rake.
Also you can run rake db:migrate --trace to get additional error information.
The deprecation warning is still just a warning, and it shouldn't be causing you any issues. The part of that error that is relevant is the No such file to load -- radius. You probably need to follow the instructions for installing Radiant, which include running a gem install radiant before dropping this project code somewhere.
Bundler manages installing and using the gems in your Gemfile, and if a Gemfile.lock is present it'll use those exact versions. This means you can't run Radiant with Rails 3.0.5 since the Gemfile specifies 2.3.14. Bundler will install Rails 2.3.14 and its dependencies automatically, though, so you don't need to worry about it.
By the way, this project looks like it has been very mismanaged. It's not common for a Rails project/gem to force you to actually clone it to use it. If you want to check out a Rails 3 project to learn from, I have a slim Rails 3 app that was intended to be an API up publicly on Github with some really clean code: http://github.com/coreyward/instavibe
My question has already been asked here, but I am trying to understand the reasons behind it as opposed to how to work around it.
The error I got was;
You have already activated rspec-core 2.7.1, but your Gemfile requires rspec-core 2.6.4. Using bundle exec may solve this. (Gem::LoadError)
Now I have been given various solutions like using "mpapis-bundler", or to create a shorthand for "bundle exec", but I was under the impression that that was what
$bundle install --binstubs
was for.
More specifically, since I have no version numbers stated in my gemfile for rspec-rails, why do I have this incompatibility? My error also occurred when I tried
$rake db:migrate
telling me that
You have already activated rake 0.9.2.2, but your Gemfile requires rake 0.9.2. Consider using bundle exec.
Any explanations would be appreciated.
EDIT:
All my gems for my app are in a gemset, and I have updated my gems again. Should an update not make sure that related gems are compatible?
This happens when you install more recent gems in your system than the one in your Rails app.
Bundler simply tells ou that you must stick with those your Gemfile states.
This is the purpose of running:
bundle exec rake db:migrate
-> running the very same rake version your Gemfile provides.
Concerning updating gems from gemfile, simply do:
bundle update
The easiest way to avoid this kind of boring stuff is to isolate your gems by creating gemsets. I use RVM for this purpose.
Regarding the rake version 0.9.2.2, either ways to do is create a new gemset for the project and maintain the gem version matching your Gemfile.
For instance if there are two rake gem containing versions 0.9.2 and 0.9.2.2, specifying rake version '0.9.2' though installs, but does not run any tasks apart from blowing error saying
'You have already activated rake 0.9.2.2, but your Gemfile requires rake 0.9.2. Using bundle exec may solve this.'
I expect bundle install to lock the gem version in Gemfile.lock and pick the rake 0.9.2, but it looks in the gemset, where by default rake 0.9.2.2 is enabled.
Just reminding the purpose of bundle install from agile web development with rails book,
'bundle install will use the Gemfile.lock as a starting point, and install only the
versions of the various gems as specified in this file. For this reason, it is
important that this file gets checked into your version control system, as this
will ensure that your colleagues and deployment targets will all be using the
exact same configuration.'
but it doesn't work that way,
The better is to uninstall rake 0.9.2.2 and use rake 0.9.2 or, use bundle update rake, that updates the rake version in Gemfile.lock to 0.9.2.2
As #apneadiving said, running "$bundle install" updates all your bunldes. However, after running "$bundle install --binstubs" I still got errors for incompatible gems whenever I omitted the "bundle exec" part.
Subsequently I needed to update my Gemfile as I added another gem, and now they work. I'm assuming the incompatibilities were solved by the gem creators.
Our project is Rails 2.2.2, maybe it can't use Bundler? (or maybe for some other reasons, Bundler cannot be used)
Then in that case, what is the most preferred way of freezing the gems into the project source tree?
Some that I know of are:
rake gems:freeze
needs gemsonrails and it doesn't work with the current gem 1.3.7
rake gems:unpack
will not freeze the depended gems. have to add it one by one manually
script/plugin install
need to install the depended gems one by one as well
you can unpack the gems into your vendor directory. once they are on the server just run rake gems:unpack and that will build them like how plugins are built or at least put into the file structure.
I've done this not for dependency and upgrade issues but for shared hosts, hosts without gem support, and actually to modify gems that need a one liner tweek.
we use rake gems:unpack and rake gems:unpack:dependencies.