Without a file extension I can't get syntax highlighting to persist. That's not the end of the world, but I'd appreciate having it.
Will it break Rails if I rename Gemfile as Gemfile.rb ?
It looks like you can rename it, but bundler will not automatically find it.
However, you can just prepend every bundler command with BUNDLE_GEMFILE=Gemfile.rb and it'll work:
BUNDLE_GEMFILE=Gemfile.rb bundle install
You might also look at http://gembundler.com/man/bundle-config.1.html -- It mentions a gemfile option, but I couldn't get it to work (even after manually setting it to Gemfile.rb, it still tried to look for Gemfile).
Related
I would like to use gems 'better_errors' and 'binding_of_caller' for my debugging in rails app, but i DON'T want to include those in Gemfile. Is it possible to do? My first thought was to simply
gem install better_errors
gem install binding_of_caller
but it doesnt work, i mean installation finishes without problems, but thats it, gem doesnt seem to work at all when i run my app on localhost. Do I need some kind of config set, anybody?
but i DON'T want to include those in Gemfile. Is it possible to do?
Yes, it is possible. You can just download the respective directories in desire folder (ex. lib) and add that gem class in your initializer so it will be loaded at the time of starting. Configuration varies as per gem.
My first thought was to simply .... but it doesnt work,
Ofcourse, it wont. How can your rails app magically detects without knowing it that you have better way to show error. It is simply saying like you have cancer formula and doctors automatically applied that formula to there patient without you telling them. There should be some commucaition between two parties rails-app and gem so they can coordinate and work better.
Do I need some kind of config set, anybody?
Yes, explained above.
i dont want to force those gems on my coworkers. KRUKUSA any more details? // said in comment
Yes, including this gems in your rails app can do this job. This extension will be available automatically to your worked. (no force applied :P)
it looks like all you want to not show those gems to other co-worker, if so, you can use this trick with git.
To achieve this thing, first simply add the gems in your gemfile, run bundle and then make it untrackable with git. You can put Gemfile and Gemfile.lock in your .gitignore file. or you can add the first add the gems and mark it ignore with below command. Read more here
git update-index --assume-unchanged Gemfile Gemfile.lock
Another possibility would be to create your own environment and use it accordingly.
Have your own configuration for myenv:
$ cp config/environments/{development,myenv}.rb
In config/database.yml, add the environment myenv and use the same config as development:
development: &development
<rest of the code you have on config/databases.yml>
...
myenv:
<< *development
In Gemfile add your custom gems to use on your mydev group:
group :myenv do
gem 'better_errors'
gem 'binder_of_caller'
end
Run rails and rake with RAILS_ENV like this: RAILS_ENV=myenv rails c
The advantage of this approach is that you still get the updates from Gemfile from the repo, and if you need to add a gem in the Gemfile for everybody to see, you still can.
Also, nobody will see the gems you installed inside the myenv group in your Gemfile.
I've added awesome_print to my ~/.irbrc file like so:
require 'ap'
Inside a Rails project directory, if I run irb it loads the gem fine, because I've already installed the gem locally. But if I run rails console, it spits out this error:
cannot load such file -- ap
How can I resolve this? I am guessing that it's looking for the gem in the app's Gemfile, but I don't want to add it to the Gemfile because I don't want other developers requiring that dependency. I only want to use awesome_print on my machine.
I am also using rbenv, if that is of any help.
There is this trick.
What you need to do is
# Copy the definition of the debundle! method into your ~/.irbrc
# Call 'debundle!' from IRB when you need to.
(as explained at the top of the file)
The text as it appears on the referred to site:
debundle.rb allows you to require gems that are not in your Gemfile when inspecting
programs that are run with Bundler.
Use at your own risk!
Paste the code of debundle.rb and you are done! A good place would be your .irbrc file
before requiring irbtools.
The code is directly taken from pry-debundle.
Please look there for any further information. This repo exists to simplify debundling
without using the pry repl.
I'm trying to get the spree_i18n gem working, but am not quite getting it.
I've added this to the Gemfile:
gem 'spree_i18n', :git => 'git://github.com/spree/spree_i18n.git'
I'm using RVM, so bundle installed it to:
~/.rvm/gems/ruby-1.9.3-p125#spree/bundler/gems/spree_i18n-e5e3e189c843
instead of the usual location at:
~/.rvm/gems/ruby-1.9.3-p125#spree/gems/
so I'm not sure if RVM is doing something weird.
But running any of the rake spree_i18n:xxx commands results in the following error:
'Don't know how to build task 'spree_i18n:new'
I'm guessing it's because the gem isn't getting picked up by rake and the app. I was thinking that the app should have picked up on the .yml translation files from the gem folder so I would not need to copy them over to the main app folder.
As a quick fix, I copied over the .yml files from the gem folder to the app config/locales folder. It works but definitely feels like a hack.
Can someone please point me in the right direction to integrate this gem correctly?
I've also posted the question here, in case, there's additional information that might help to solve this.
https://groups.google.com/forum/?hl=en&fromgroups#!topic/spree-user/6ycWGfm6eTk
Thank you for your time!
see related closed issue on github
https://github.com/spree/spree_i18n/issues/171
So I have a gem in /vendor/bundle that needed to be fixed, and when I edit one of the files and then run bundle install it links up properly and all is good. But the problem is that when I deploy my project, the edits to my gem are lost because it runs bundle and saves the gems in a separate shared directory.
It seems that the solution to this is to make a vendor/static_gems directory, and place the gem inside of there, and link it like:
gem 'ruby-mysql', :path => "vendor/static_gems/ruby-mysql-2.9.3"
But I get an error that the gem is not found. is there something wrong with my path? Or something wrong with what I am placing there? When I copy this gem from the gems/ folder all that is in there is a lib/ directory with some .rb files.
Most probably you don't deploy your Gemfile.lock with your project, so Bundler runs without (or more probably) with an outdated one that links to the other gem path.
Be sure to update the Gemfile.lock with the rest of your project and you shouldn't need to worry about a static gem path or something like that.
I think I had the right idea, but I wasn't putting the whole gem into the static_gem folder, just the lib directory. It works great when the whole gem is in there.
I'm writing an app that will run scripts in a specified folder, and then record the numbers and graph them.
My problem is that if the script is a ruby file, the require statements fail inside the script because bundler seems to have done something funky with the load path.
Running rails runner Datasource.run_jobs fails:
class Datasource < ActiveRecord::Base
def self.run_jobs
require 'aws_sdb'
access_key_id = "REDACTED"
secret_key = "REDACTED" # In all actuality these woudln't be here.
#sdb = AwsSdb::Service.new(:access_key_id => access_key_id, :secret_access_key => secret_key)
Datasource.all.each do |ds|
puts "Updating #{ds.name}..."
unless #sdb.list_domains.include? ds.name
puts "#{ds.name} doesn't exist in SDB, creating a domain for it..."
#sdb.create_domain ds.name
end
#data = "TEST"
data = `#{RAILS_ROOT}/lib/plugins/#{ds.name}`
#sdb.put_attributes(ds.name, Time.now.to_i, data)
puts "Data Collected: #{data.inspect}"
end
end
has_many :graphs
end
(Basing this off your comments on the question)
You will need to add hpricot (and any other gem this needs) to your Gemfile so that they are made available by Bundler. Bundler is by far the easiest way to avoid gem conflicts and tomfoolery.
Imagine this situation: You somehow lose the gems that you have currently. Be this happening through a format or system change or any other reason. Whatever it is, you've lost your gems. How are you going to re-install all your gems? You could keep a list of them somewhere else yourself, but is this truly likely?
Bundler solves this problem by making you state what gems your application requires and only adding those gems to the load path, which is why you can't find hpricot. When you run bundle install the first time, this creates a Gemfile.lock which contains something like this:
GEM
remote: http://rubygems.org/
specs:
abstract (1.0.0)
actionmailer (3.0.0)
...
Because you commit this file to your source control "solution" of choice (be it Git, SVN, FTP, whatever, it's not important) you have a solid way of specifying the precise gems and precise versions of those gems that your application uses.
When/If your gems are wiped, you can simply clone your project again and run bundle install. Because the Gemfile.lock file exists, you'll have exactly the same gems you had originally, even if there were updates.
If you don't want the exact same gems, just run bundle update and this will ignore the specifications in Gemfile.lock and instead revert to depending on Gemfile to define them. This will check for new versions of gems and install them, updating the Gemfile.lock when it's done.
Honestly, I don't understand the Bundler hate. If you could explain in wider terms than "OMG IT SUCKS YEHUDA IS SATAN", I'd be much obliged.
Edit: WedTM asked for a sample Gemfile and related code:
In the Gemfile you'd have this:
group(:scripts) do
gem 'gem1'
end
To require these gems for your scripts:
require 'bundler'
Bundler.require(:scripts)
You may also wish to require the default gems too which you can do by just adding default anywhere to the arguments of require:
Bundler.require(:default, :scripts)
If this for some reason doesn't work I would imagine it would be because it can't locate the Gemfile. This can be fixed by setting the ENV['BUNDLE_GEMFILE'] to the path to the Gemfile.
I wonder if you might be able to use RVM to set up the ruby environment before running your scripts. Maybe something with a gemset like:
data = `rvm gemset use scripts; #{RAILS_ROOT}/lib/plugins/#{ds.name}`