Here's a quick rundown for bundler and production WRT development/test dependencies.
At runtime, an application uses:
require 'bundler' Bundler.setup
to have all dependencies loaded. In a Rails application, these lines can be found in the file config/boot.rb.
By default Bundler.setup loads ALL dependencies. In production this doesn't work so well as it will inevitable load in dependencies specific to development and test. There are however, two ways to prevent this.
The first way is to specify which dependency groups to load. For example:
Bundler.setup(:default)
would load only those dependencies specified in the default group. Ie, ignore any dependencies specified in named groups eg, :development, and :test.
The problem with this approach is that config/boot.rb is a Rails provided file and is subject to change between versions. It could of course be patched but aside from the overall ickiness of this, there's no guarantee that the code would remain in this file.
The other option available is designed specifically to handle production environments.
If you execute:
$ bundle install --without development test
Bundler will create a .bundler/config file in the root of the project. This file will look something like:
--- BUNDLE_WITHOUT: development:test
When Bundler is subsequently run, it will NOT attempt to load the named dependency groups (even though they are still listed in the Gemfile.lock).
Thus if we were to ship the product with this file, there would be no need to have the development/test dependencies installed on a production machine.
Additionally, I consider it good practice to ship a production Rails application that excludes specs, features, test and development environment configurations, and any test/development specific rake files.
P.S. I know it's planned but I'd also like to add my support for committing Gemfile.lock.
Hope this helps,
Simon
On Tue, 2011-08-02 at 00:02 +1000, Simon Harris wrote:
Here's a quick rundown for bundler and production WRT development/test dependencies.
At runtime, an application uses:
require 'bundler' Bundler.setup
to have all dependencies loaded. In a Rails application, these lines can be found in the file config/boot.rb.
By default Bundler.setup loads ALL dependencies. In production this doesn't work so well as it will inevitable load in dependencies specific to development and test. There are however, two ways to prevent this.
The first way is to specify which dependency groups to load. For example:
Bundler.setup(:default)
would load only those dependencies specified in the default group. Ie, ignore any dependencies specified in named groups eg, :development, and :test.
The problem with this approach is that config/boot.rb is a Rails provided file and is subject to change between versions. It could of course be patched but aside from the overall ickiness of this, there's no guarantee that the code would remain in this file.
The other option available is designed specifically to handle production environments.
If you execute:
$ bundle install --without development test
Bundler will create a .bundler/config file in the root of the project. This file will look something like:
BUNDLE_WITHOUT: development:test
When Bundler is subsequently run, it will NOT attempt to load the named dependency groups (even though they are still listed in the Gemfile.lock).
Thus if we were to ship the product with this file, there would be no need to have the development/test dependencies installed on a production machine.
+1 to this approach
Additionally, I consider it good practice to ship a production Rails application that excludes specs, features, test and development environment configurations, and any test/development specific rake files.
We have the basic structure in place for a -devel package, we have just been waiting on getting the require test deps into rpm format before enabling it. That said, the paths of what gets actually included in that rpm may need a little cleanup when we start using it, though I think Chris already has it pretty close to correct.
P.S. I know it's planned but I'd also like to add my support for committing Gemfile.lock.
Hope this helps,
Simon _______________________________________________ aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
aeolus-devel@lists.fedorahosted.org