How do I freeze gems into a Rails 3 application?

I haven't had to do this yet, but I believe it's all handled by bundler When you create a new rails3 app, the rails dependencies are put into your Gemfile You can run bundle install to install them. By default, they are installed into your BUNDLE_PATH If you want to install them within your app, you can specify where: bundle install vendor/gems.

I haven't had to do this yet, but I believe it's all handled by bundler. When you create a new rails3 app, the rails dependencies are put into your Gemfile. You can run bundle install to install them.By default, they are installed into your BUNDLE_PATH.

If you want to install them within your app, you can specify where: bundle install vendor/gems.

1 You can also run "bundle pacK" and they will end up in the "vendor/cache/" directory. – coder_tim Oct 12 '10 at 20:44 To clarify (as a comment to this answer, based upon other answers and comments to those answer), freezing gems isn't as useful as it once was if you're using Bundler to manage your gem dependencies because Bundler provides most of the functionality previously afforded by freezing gems. – Kenny Evitt Mar 15 at 19:21 As other answers and comments have said, this is only the right approach if you need to freeze your gems into your app, usually because you have modified them.

– nfm Mar 15 at 21:28.

DO NOT USE THE "RECOMMENDED" ANSWER BY NFM! Instead, review the Bundler site, particularly the page on deployments: gembundler.com/deploying.html The short summary is to use specific versions in your Gemfile and run bundle install --deployment on each target system where you need the exact gem versions. Using the --path option will install the gems, but it's not really what you want to URL2 Matt Enright said, you just bloat your SCM with stuff that bundler can handle smartly on each target environment.

So, the short answer is, you don't. When you modify your Gemfile, and then run bundle install or bundle update, bundler handles the dependency resolution for you and determines the best (newest) versions of each gem you've required that satisfies the entire dependency chain (you won't get a new version that breaks another gem in the dependency list, etc. ). You can also of course place a specific version, or a '>= 1.2.3' specification or whathaveyou in the Gemfile using the familiar syntax from the config.

Gem days, and bundler will make sure to satisfy that as well (or won't produce a Gemfile. Lock if there is no valid resolution). When Bundler does its business, it creates the Gemfile.

Lock file, which (and this is provided you use bundler alone for managing your gem on all workstations/environments/deployments) performs the same function as freezing all of the gems you've required. For free!(Check this file into version control!) If your new development intern pulls down your source on a fresh machine, it takes one bundle install and the exact same versions of the gems that you have installed are on her machine. Push to deployment, and do a bundle install --deployment there (or more likely, throw it in your Capfile), and the same gems are installed (this time into vendor/bundle, configurable).

Bundler is used in Rails 3 to manage loading all of the gems, so wherever you've told bundler to install them (whatever your normal gem install location is by default, or BUNDLE_PATH (which is recorded in . Bundle/config if you install with bundle install --path=foo otherwise), bundler will load the right ones, even when they differ from system gems. You don't need to unpack the gems and check them in to your app, because it doesn't matter: you're guaranteeing the same versions are being called regardless of where they are installed, which will likely vary from machine to machine anyways (.bundle/ should not be checked in to the repo) - so why stick another 60-80 MB of files into your repo that you won't ever be changing or using?(incidentally, this is why I wouldn't recommend a bundle install --path=vendor/gems like nfm suggested - it's not necessarily wrong, there's just no benefit to it over the normal bundler workflow, and now your repo size just ballooned up).

I inherited an existing Rails 2. X app running on Heroku and I've had a hard time figuring out the why one would want gems installed under . \vendor\plugins versus just adding them to the bundler Gemfile.

– Kenny Evitt Mar 14 at 2:34 My best guess for that is that because prior to Bundler, the best practice was "vendor everything" so that you could have a consistent installation set across all of your workspaces/deployment targets (traced back to this blog post, as best as I can tell), and that when you see bundled gems stuck in vendor it's just using the old pattern and not taking full advantage of Bundler. – Matt Enright Mar 14 at 14:19 – you're almost certainly correct. What helped in understanding the many different options available is that although a (Rails) plugin can be packaged as a (Ruby) gem, gems aren't always plugins.

But I finally realized that the reason why there were 'gems' installed under . \vendor\plugins is simply that (a) they are plugins, and (b) the previous developer chose to adopt the (reasonable) convention of vendorizing (plugin) gems in that folder (instead of say . \vendor\gems).

– Kenny Evitt Mar 15 at 19:19 A big issue here is that the context to which the application is being used is important. The environment the deployment is taking place in could be limiting -- which a bundle install may not be supported. On Site5 shared web hosting you are unable to install gems due to memory issues with RubyGems... Storing to SVN/Git is not a bad way to go in this case.

– Mike Jul 20 at 21:48.

Assuming you already have bundler gem installed: $ bundle lock $ git add Gemfile.lock.

The newest bundler now locks by default on bundle install. – David Lyod Aug 5 '10 at 6:18 The command is deprecated for the latest Bundler. – Millisami Mar 24 at 12:39.

Well I have to modify slightly one of the gems I need. So I need to keep it inside my Repo. So what NFM mentioned is what I probably need...

Pod - If you need to modify the gem, the best practice to do this would be forking the project, making the change, then using the 'git' flag in bundler: git 'some_gem', :git => 'git://github. Com/me/my_forked_some_gem. Git' This way you'll be notified when the gem is updated.

The command that you want is bundle package which just unpacks the gems and dependencies at vendor/cache folder. But just a notice, the :git => .... kind of gems won't get packaged. You have to hack a way out for :git => ... related gems to get packed.

I had to do this for typus gem deployment on Heroku as you can't run a heroku rails generate typus on Heroku given it's a read only file system. I didn't want ALL gems put into my app, just the one that was causing me grief. Here are the steps that lead to success: create directory in app_name/vendor/gems/gem_name (optional) ... in my case /app_name/vendor/gems/typus add the following to gemfile (this tells bundle where to find and put the gem source): gem 'typus', :git => 'https://github.Com/fesplugas/typus.

Git', :path => "vendor/gems/typus" then from within your app directory (this installs the gem into your app): 'gem unpack typus --target vendor/gems/typus' then bundle install then .. in my case... commit and push to repository and then deploy up to heroku... you may have to run a heroku rake db:migrate.

I think what you are looking for is bundle pacakge checkout the man pages here: gembundler.com/man/bundle-package.1.html.

A lot of comments are somewhat saying that it's not useful to use the bundle install --path vendor/gems, but those people who are using Dreamhost, it should note that you cannot use bundle install in Dreamhost. The solution is to get all the gems into the vendor folder and upload the whole thing to the Dreamhost directory. There are other solutions to turn around this, but it's much more complicated to do.

You can bundle install on dreamhost without any issues. If you are on shared the environment is already setup to store them locally in your home directory. If you are on a VPS or Dedicated you can run bundle install as root or just add this to your .

Bash_profile export GEM_HOME=$HOME/. Gems export GEM_PATH=$GEM_HOME:/usr/lib/ruby/gems/1.8.

Well, Bundler is going to freeze all of them, and the idea is that you want to freeze not only a single gem, but the collection of gems that produced a working copy of your app That being said, on your local dev machine, you can do bundle update name of gem and it will update just that one gem to the latest version within the restrictions specified in your Gemfile which also updates your Gemfile. Lock which effectively updates just that one gem on Heroku when you next deploy.

Well, Bundler is going to freeze all of them, and the idea is that you want to freeze not only a single gem, but the collection of gems that produced a working copy of your app. That being said, on your local dev machine, you can do bundle update name of gem and it will update just that one gem to the latest version within the restrictions specified in your Gemfile, which also updates your Gemfile. Lock, which effectively updates just that one gem on Heroku when you next deploy.

Hm, I tried both bundle update gdata and bundle update gdata vendor/gems (gdata is obviously the gem I need to modify), and both commands simply updated the gem in-place, overwriting my modified version. Given that this is the most upvoted answer, I must be missing something. – Dan Oct 7 at 6:37 Sorry to disagree, but I suspect that the correct answer here is the one from @tadman, and that normalocity didn't read your question carefully enough - no offence intended guys ... – chrispanda Oct 7 at 7:02 if I'm wrong, I'm wrong - popular answers aren't always correct.

I upvoted tadman's answer after reading through it again. – normalocity Oct 7 at 12:29.

If you're using bundler, which is the default for Rails 3, you can always fork the gem to your own git repository and add that definition to your Gemfile with whatever location it can be found at: gem 'thegem', :git => 'git://github. Com/cloned_to_me/thegem. Git' Another option is to use bundle package to save copies of the gems in vendor/cache.

These can then be later installed using bundle install --local according to the documentation. This is the closest thing to the Rails 2 "freeze" method, but has the added advantage of saving the gems before they are installed, not after, avoiding any platform-specific problems as was the case previously.

Trying out your second option first: bundle package appears to work but—on closer inspection—it doesn't actually bundle my changes. I've verified that the version specified in bundle show gdata has my patch, but the version cached by bundle package is the unmodified version of the gem. The bundle-package doc states that it only operates on .

Gem files (so not the installed gem directory? ). Any want to freeze my specific version?

– Dan Oct 7 at 7:35 Also, it looks like Github no longer supports gem building so I'm not going to go that route, and Jeweler (one of their recommended replacements) pushes automatically to RubyGems, which I'm not ready to do at this point, given that I'm a Ruby rookie. – Dan Oct 7 at 7:45 1 p.s. Added the question above as a proper question, so if anyone answers here you might want to answer there as well to get proper credit :) – Dan Oct 7 at 7:57 Pushing gems to rubygems.Org has never been easier, so I wouldn't be too shy about it.

All you really have to do is register and come up with a unique name for your gem. You can also have a private gem repository if you'd rather not publish it. – tadman Oct 7 at 15:05 1 A word of caution to those using bundle install --local: doing so will update the default setting for bundle so all future bundle install commands will use the --local switch.

You can reverse this setting with bundle install --system – Dan Oct 77 at 22:19.

With thanks to those who answered the question with related approaches, I ended up going with the approach mentioned in this sister question. For the sake of clarity, this is what I did: Repackage modified gem as its own gem. This takes a little finagling but is described well in the RubyGems Guides.

Move said gem into your source directory (I used vendor/gems) In the project's Gemfile, point to the location of the new gem: gem "modified_gem", :path => "vendor/gems/modified_gem" Add new gem to version control, make sure bundle install isn't messed up with funky settings (e.g. --local), and cross your fingers. Someone also mentioned that it's possible to mix in changes to the gem instead of overriding source files. I don't know anything more about this technique except that it should be possible.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.