We're using bundler, and on deploy server application is installed without some gems
bundler install --without test
In this case some code should be deactivated (like loading rspec && cucumber task into Rakefile)
Is there some simple methods like Bundler.installed?(:test) то detect this case?
What you are basically trying to do is distinguishing your production environment from your development (or test) environment. You should not rely on the installed gems for this, but Bundler groups can still be useful.
I would recommend using an environment variable, for example like in Rails. Then you could set this var in your server config with
$ export MYAPP_ENV='production'
and load it into your application with the default value :test:
MYAPP_ENV = ENV['MYAPP_ENV'].to_sym || :test
This way, you can always tell if you are on the production server. Suppose your Gemfile looks something like this:
source :rubygems
gem "sinatra"
group :test do
gem "rspec"
gem "faker"
end
You can then require only the relevant gems with
Bundler.require(MYAPP_ENV)
Back to your original question: Now it is very easy to check if you are on your production machine or not, by simply using MYAPP_ENV again:
if MYAPP_ENV == :test
# do some test specific stuff
end
I hope this helps.
Related
When I Bundle.require(:default) I'm getting an error saying that one of the gems in my test group isn't found. I installed this bundle --without test so this makes sense, but shouldn't all the gems in the :test group be ignored here? Isn't that the point?
Thoughts on what might be wrong with this environment?
EDIT:
It may have something to do with my setup for this projects. I'm caching the gems in vendor/cache with bundle package --all. My cache has gems from git, file, and traditional sources. Bundler is reporting
some gems appear to be missing from your vendor/cache -> could not
find gem factory_girl which is required by
try editing the gemfile so that it fg is like this:
group :development do
gem 'factory_girl'
end
Then it won't look for it in the testing group. Or, I can't tell which group you actually want it in, but my point is limit it down to the group you want.
Also, try running Bundler.require(:default, Rails.env) instead of just (:default). That would put it back to the standard Rails requirements.
Finally, I figure you're trying to install the gems for development(or production?) have you tried running bundle install --without test production to make sure that nothing is coming in from the other group you aren't focused on?
Edit:
Last try before I'm out of ideas. From the documentation it seems like you can specify the load path as well as requiring them. Try setting Bundler.setup as well? I don't have a rails environment on this machine so I can't test.
Bundle.setup(:production)
Bundle.require(:production)
or
Bundle.setup(:production, :default)
Bundle.require(:production, :default)
I am using RubyMine (v6.0.2), but my teammates are not, so they need the "debugger" gem in the gemfile. I can conditionally un-require the Gemfile when running RubyMine (so the Gemfile can be shared and identical), but since the 'debugger' gem is not included, the Gemfile.lock file changes depending on whether the project was last run with RubyMine or not. This creates a lot of noise in redundant Gemfile.lock changes.
I've tried using 'debugger-xml' gem; that doesn't solve the issue.
So -- how can I run RubyMine 6.0.2, with the 'debugger' gem in the Gemfile, without having Gemfile.lock change?
I've been working on this issue from the other side of the table. I use the debugger gem, but have team mates that use RubyMine.
We discussed several potential solutions but they all involved conditional checks in the Gemfile that would result in a modified Gemfile.lock.
I googled around for a better solution and found this SO post: How to use gems not in a Gemfile when working with bundler?
Combining a few of the answers in there, I came up with this solution:
Remove the debugger gem from the Gemfile.
Create a Gemfile.local with the contents below.
Add Gemfile.local to the .gitignore file if using git.
Create a function and shell alias.
Start rails with $ be rails s
How it all works!
Bundler will use the file named Gemfile by default, but this behavior can be overridden by specifying a BUNDLE_GEMFILE environment variable. Bundler will use/create the lock file with the same name as the BUNDLE_GEMFILE.
The shell function __bundle_exec_custom will check to see if there is a Gemfile.local file in the CWD. If there is, then the BUNDLE_GEMFILE variable is set and used. Otherwise, the default Gemfile is used.
This will allow a developer to use any gems that they want for local development without having to impact the application as a whole.
Gemfile.local:
source "https://rubygems.org"
gemfile = File.join(File.dirname(__FILE__), 'Gemfile')
if File.readable?(gemfile)
puts "Loading #{gemfile}..." if $DEBUG
instance_eval(File.read(gemfile))
end
gem 'debugger'
Function and shell alias:
__bundle_exec_custom () {
if [ -f Gemfile.local ]
then
BUNDLE_GEMFILE="Gemfile.local" bundle exec $#
else
bundle exec $#
fi
}
# Rails aliases
alias be='__bundle_exec_custom'
I think I found it. Apparently, RubyMine does not deal well with the debugger gem being required into the Rails app, but has no issue with the gem just being installed.
The solution then is to include the gem in the Gemfile (and Gemfile.lock) but only require it outside RubyMine.
gem 'debugger', {group: [:test, :development]}.
merge(ENV['RM_INFO'] ? {require: false} : {})
The above code is from this comment on the JetBrains bug tracker, through this comment on a similar question.
It checks for the presence of the RM_INFO environment variable, which is set by RubyMine. The important thing is that it only affects whether the gem is required and thus should not change Gemfile.lock between installs.
I may have an even better solution that seems to be working for me in my Rails 4 app...
In your Gemfile, move all your debugging-related gems to their own group, as such:
group :pry do
gem 'pry', '>= 0.10.0'
gem 'pry-debugger', '>= 0.2.3'
gem 'pry-highlight', '>= 0.0.1'
end
In config/application.rb you will a find something like the following:
# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)
Add the following just below that:
Bundler.require(:pry) unless ENV['RM_INFO'] || Rails.env.production?
You may wish to modify the unless condition to suit your needs, but the important part is that RubyMine will set RM_INFO, which you can use to detect and therefore exclude gems from being required.
This will eliminate the ping-pong effect of bundling in RubyMine vs. command line, so this should work well in a mixed-IDE team.
One last note, if you're deploying to Heroku, you might want to exclude the :pry group from being installed on deploy:
$ heroku config:set BUNDLE_WITHOUT="development:test:pry"
So I know that in a Gemfile I can do something like this:
group :development, :test do
gem 'gem1'
gem 'gem2'
end
What I am looking to accomplish is something like this:
group :production do
gem 'gem1'
gem 'gem2'
end
group :development, :test do
gem 'gem1', :path => '/Documents/Code/gem1/'
gem 'gem2', :path => '/Documents/Code/gem2/'
end
So our application uses 2 gems that we also develop locally. In order to improve time while developing on our local machines, we want to be able to point our dev environments to the local copies of the gems - this way it picks up all changes without needing to restart our rails server. Otherwise we would have to rebuild the gem, re-install the gem, and restart rails with every development change in the gem.
However, doing this gives me the following error:
You cannot specify the same gem twice coming from different sources. You specified that gem1 (>= 0) should come from an unspecfied source and source at /Documents/Code/gem1
I have tried even running something like bundle install --without production and I get the same error.
Does anyone know if it IS possible to do what I would like to do?
Thanks!
i think that there is a supported way to do it and some hacks to work around it.
supported way:
use bundle config with the local option as described here: http://bundler.io/v1.3/man/bundle-config.1.html
hacky way:
use env vars and execute bundler before using in production: http://www.cowboycoded.com/2010/08/10/using-2-sources-for-a-gem-in-different-environments-with-bundler/
there is a feature-request for this problem on github with several related issues and lots of comments: https://github.com/carlhuda/bundler/issues/396
the github issue phoet linked to is resolved, and is consistent with the supported way.
I dug around through the docs, you'll need to set the config variable and updated your gemfile to reference the branch as well.
e.g.
edit your Gemfile:
gem <gem_name>, git: <git_url>, branch: <branch>
on command line:
bundle config local.<gem_name> <local_path_to_gem>
I solved this by creating a new Gemfile that's identical to the original except for the target gem's source. Then, in config/boot.rb, I used:
require 'rails'
if Rails.env.development?
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../DevGemfile', __FILE__)
else
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../ProdGemfile', __FILE__)
end
When using bundler with a project in general and Rails specifically, you have access only to gems defined in your Gemfile. While this makes sense, it can be limiting. Mostly I find it limiting when I want to use a certain RSpec formatter that the rest of the team doesn't use. Unless it's in the Gemfile, it isn't accessible.
Any way around it or I have to add it to Gemfile?
Update: my problem wasn't Bundler but Spork. When running RSpec without Spork I had no problem of using whatever formatter I wanted.
Update #2: it looks like that using Bundler is still the cause of the problem. The difference between using Spork and not using Spork, is that when running RSpec without Spork, it loads the formatter before loading your project and getting into the Bundler "sandbox".
With Bundler:
$ bundle exec irb
>> require 'fivemat'
LoadError: cannot load such file -- fivemat
from (irb):1:in `require'
from (irb):1
from /Users/arikfr/.rvm/rubies/ruby-1.9.3-p194/bin/irb:16:in `<main>'
Without Bundler:
$ irb
>> require 'fivemat'
=> true
In ChiliProject we allow users to create a Gemfile.local which is included into the main Gemfile on load. This allows users to specify additional gems without having to change our Gemfile to ease updates.
For that, we have included the following code at the bottom of our Gemfile.
gemfile_local = File.expand_path('Gemfile.local', __dir__)
if File.readable?(gemfile_local)
puts "Loading #{gemfile_local}..." if $DEBUG
instance_eval(File.read(gemfile_local))
end
The Gemfile.local itself is excluded from the repository via .gitignore.
I assume that none of these answers have been chosen as correct because they don't do a great job of solving the problem: having additional gems that you can use that by default don't require any changes to files already in the repository to achieve. That is, you don't have to modify any files, and you don't have to live with remembering not to check in your local changes. Here's how I do it.
The idea is basically inverting the dependencies of Holger's answer, such that there's no need to modify the shared Gemfile. Bundler allows one to specify which file is to be used as the gemfile, but strangely the documented methods do not apparently work with its configuration file and will not be fixed. There is a somewhat obscured feature of Bundler that any of the configuration options can be set in an environment variable or passed on the command line. Running all of your commands as bundle [command] --gemfile [yourgemfile] or BUNDLE_GEMFILE="[yourgemfile]" bundle [command] will cause Bundler to read whatever gemfile you want it to. I highly recommend using the environment variable approach, and either creating an alias or exporting the variable for your current session, particularly as I was unable to use the command line switch with the "exec" command.
Therefore, I run rspec like this: BUNDLE_GEMFILE="[mygemfile]" bundle exec rspec [filename], and I have the first part of this aliased as bem in my bashrc. Works like a charm.
Then, you should setup your source control to ignore your Gemfile, either in the project's .gitignore or, to keep the project entirely hygienic without changing even its .gitignore, to your personal global ignore file (which is by default in ~/.config/git/ignore and has the same format as a project's gitignore file).
One other thing to note is that Bundler will create a lockfile based on the Gemfile's name. This is super handy, as it keeps you from overwriting your project's Gemfile.lock if it's checked in, but you need to ignore this new lock file as well. If your gemfile is Foo.bar, look for Foo.bar.lock.
Finally, you can do something similar to Holger's suggestion in your custom Gemfile:
source "http://rubygems.org"
gem "fivemat"
instance_eval(File.read(File.dirname(__FILE__) + "/Gemfile"))
and you're good to go, as long as you remember to specify your Gemfile.
You can use something like this in your Gemfile:
gem 'foo' if ENV['ENABLE_FOO_GEM']
Then just set ENABLE_FOO_GEM in your environment.
export ENABLE_FOO_GEM=1
The gem will be disabled by default, but easily turned on (permanently) by anyone who wants to use it.
Add to .gitignore
Gemfile.local
Gemfile.local.lock
Add to the project a Gemfile.local.sample file with the following content:
# Include gems that are note meant to be part of the project but for development purposes
# That's why Gemfile.local and Gemfile.local.lock must be git-ignored
# To use these gems:
# 1. Create a "Gemfile.local" file (at same level of "Gemfile")
# 2. Prepend "BUNDLE_GEMFILE=Gemfile.local" before "bundle install" or "bundle exec rails c" and so forth.
eval_gemfile "./Gemfile"
group :development, :test do
# Suggested gems
gem "awesome_print", require:"ap"
gem "hirb"
gem "pry"
gem "pry-byebug"
gem "pry-rails"
gem "meta_request"
# My gems
gem "fivemat"
end
I believe the gem Devpack provides the functionality you are looking for.
The gem allows you to add a single gem to your Gemfile which will permit any developer to configure their own preferred set of development gems either for an individual project or globally by creating a .devpack file containing a list of gems.
(I am the author of this gem; I came across this post while developing it so thought it may be worth adding).
In case you still decide to do this (horrible idea):
You can add ruby code to your Gemfile to load a ~/.gemfile (or such) if it exists.
Something like:
eval(IO.read('~/.gemfile'), binding) if FileTest.exists?("~/.gemfile")
My Sinatra application was running fine on Dreamhost until a few days ago (I'm not sure precisely when it went bad). Now when I visit my app I get this error:
can't activate rack (~> 1.1, runtime) for ["sinatra-1.1.2"], already activated rack-1.2.1 for []
I have no idea how to fix this. I've tried updating all my gems, then touching the app/tmp/restart.txt file, but still no fix.
I hadn't touched any files of my app, nor my Dreamhost account. It just busted on its own (my guess is DH changed something on their server which caused the bust).
When I originally deployed my app, I had to go through some hoops to get it working, and I seem to think I was using gems in a custom location, but I can't remember exactly where or how. I don't know my way around Rack/Passenger very well.
Here's my config.ru: (mostly grafted from around the web, I don't fully understand it)
ENV['RACK_ENV'] = 'development' if ENV['RACK_ENV'].empty?
#### Make sure my own gem path is included first
ENV['GEM_HOME'] = "#{ENV['HOME']}/.gems"
ENV['GEM_PATH'] = "#{ENV['HOME']}/.gems:"
require 'rubygems'
Gem.clear_paths ## NB! key part
require 'sinatra'
set :env, :production
disable :run
require 'MY_APP_NAME.rb'
run Sinatra::Application
You could try 'pinning' your gem versions before they are required. If you have command line access to the server try this:
gem list
This should show you which gems are installed. But you do say you have some custom gem paths which may not work for this. Something is calling a 'require "rack"' with a different version to what your application is expecting. It may be Passenger, which means the best you can hope for is to upgrade to the latest version of Sinatra.
After Gem.clear_paths, you could try this:
gem 'rack', '~>1.1'
gem 'sinatra', '~>1.0' # NB use whatever gem list shows you as the version of sinatra you were using when you deployed your application.
It's the typical gem activation problem. Use Bundler to get around it.
Looks like you hit a non supportable Sinatra, Rack, Tilt version.
Take a look here how to solve that: http://codex.heroku.com/past/2010/12/14/sinatra_on_dreamhost/