I get gems to work fine on my local machine, but on Cloud9 I keep getting `require': cannot load such file. I've had this problem with multiple gems and I don't know what I'm doing wrong.
I have installed the gem, added it to my gem file and did bundle install. It shows in my gem list.
Here is the path for it from bundle show
/usr/local/rvm/gems/ruby-2.1.5#rails4/gems/test_linker-1.0.1
Here is my environment path
GEM PATHS:
- /usr/local/rvm/gems/ruby-2.1.5#rails4
- /usr/local/rvm/gems/ruby-2.1.5#global
I had the same issue. The ENV variables get out of sync between the terminal and the Runner. If you run
exec 'env'
from a ruby script, it may show different GEM_PATH and GEM_HOME than you'll see from the terminal.
To sync them, I had to remove references to #rails4 from env in the ~/.profile file. (just set them in .profile to exactly what they are in the Runner.)
GEM_PATH=/usr/local/rvm/gems/ruby-2.1.4:/usr/local/rvm/gems/ruby-2.1.4#global
GEM_HOME=/usr/local/rvm/gems/ruby-2.1.4
This Runner runs ruby scripts without Rails. If you want Rails you can create a Run Configuration based on the Ruby on Rails Runner.
It would be nice if you could change the ENV variables in the individual Runners. There is an ENV button at the top right, but trying to override GEM_HOME and path there has no effect.
Related
There is fundamental problem with ruby gem sets where commands like rake xxxx might create error because command might use global version of rake while your gemfile requires very specific version.
I know 2 ways to mitigate this.
Use bundle exec in front of rake and rails commands. For example bundle exec rake db:migrate Adding this in front makes sure command is executed in relation of the current bundle meaning the bundle that got created when you run bundle install.
Using RVM. There is less known way of creating local gemset with RVM. First you create directory for your new app in this case mkdir myapp, cd myapp and then run rvm use ruby-2.3.0#myapp --ruby-version --create for creating local gem set with nothing in it. Now you can run gem install rails and rails new . to create rails myapp with it's dedicated gem environment in the folder you are in.
As nice extra RVM will swap to right gemset every time you cd to myapp directory automatically.
As for as I understand both approaches work, but are there any known issues why you would not use one of approaches above?
If you're an RVM fan like myself, I would go with creating my own gemset for every rails project I start. This will make it easier for me to just use rake and rails commands without specifying bundle exec every time.
Put in mind when sharing your code that some developers might be using rbenv or maybe not using a ruby version manager at all. One way you can make sure that everyone is happy and working with the same version of ruby, is to provide two additional files in your project directory (.ruby-version and .ruby-gemset) and track them in your project.
The .ruby-version file would contain the version of ruby you're using for example 2.4.1. Note that this is compatible with both RVM and rbenv and will switch to the correct ruby version.
The .ruby-gemset file is identified only by RVM; thus, switching to the correct gemset you have setup for the project.
This will make your project compatible with developers using rbenv while still making those of us using RVM happy :)
Putting all these considerations in mind, now you should care less wither people use bundle exec or not!
One reason not to use (2): if anyone else wants to work with your code, they will have to duplicate all that for themselves, rather than just remembering to type bundle exec. They have likely never seen (2) before, so this is perhaps non-trivial.
I have a rails app that I'm running locally where the gems are installed in the vendor/bundle directory. I want to add some debugging statements to a gem and then test it locally. I'm running bundle exec rackup config.ru to run the server. I've tried rerunning bundle install before starting the application, but that still doesn't seem to pick up my changes. Any ideas?
Running bundle show --paths will print out exactly where Bundler is loading your gems from, so you can double-check that against the files you are editing.
As a shortcut, bundle open <gemname> will open that gem's directory in your editor of choice (whatever your EDITOR environment variable is set to). You can then edit it directly there.
There is normally no need to re-run bundle install or rebuild the gem when you edit files this way.
I'm trying to use Puppet to set up RVM on a variety of systems. Everything works fine until I try to specify which Ruby to use.
Running rvm use 1.9.3 with a Puppet exec yields an error, because 'rvm is not a function', since Puppet's exec forces all commands to be fully qualified.
How would I use Puppet to set the system Ruby through RVM? Is this even possible?
When you install rvm you need to source rvm.sh in order to get it working right away. The exact path to this file is usually disclosed in the installation messages.
You are getting good error message, it tells you that RVM can not be used interactively. This means even if RVM ignored the problem and set current ruby it would make no sense because running RVM as binary is a separate execution of shell which will not be able to set parent process (the shell / puppet) environment. To be able to set environment RVM has to be loaded as function in shell so it can change environment of current process.
So there are few ways to make it work:
subshell with multiple commands:
bash -c "source ~/.rvm/scripts/rvm ; rvm ..."
RVM set operation:
~/.rvm/bin/rvm {ruby-name} do {command}...
Some operations do not require above tricks (like setting default ruby):
~/.rvm/bin/rvm alias create default {ruby-name}
An extra explanation - default ruby is not a system ruby, it is a ruby that will be loaded when you source RVM, if you aim for availability of ruby in multiple places use alias and wrappers:
rvm alias create {my_app} {ruby-version}
rvm wrapp {ruby-version} --no-links --all
PATH=~/.rvm/environments/{my_app}:$PATH
This will create:
an alias - so it is easy to reference application ruby and no changes are needed in scripts to change ruby - just update alias
create wrappers for all gems installed in that ruby - includes wrappers for ruby and gem commands
add the PATH=... on top of any script that should work with ruby for your application.
I am attempting to deploy a small command-line application written in Ruby. Many of the gems that the application depends on are hosted on my github account. I have specified their locations in the Gemfile appropriately. When I clone the repo on the deployment machine and run bundle install from the root, all goes smoothly. I can then run the command line app (named "hippo") with bin/hippo. I would like to install the app to the system so that I do not need to patch $PATH or specify the path to the executable in order to use it.
When I run gem install /path/to/my/.gem/file, installation fails and says that it cannot resolve the dependencies to my personal gems hosted on my Github account. I gather this is because the gem install command does not read the Gemfile, only the gemspec (why on earth did the bundler people name their file Gemfile instead of BundleFile or something?), and the locations of the gems are specified in the Gemfile (there is no way to point to a github gem in a gemspec, right?). I have the same issue when I use the rake install task that comes with a bundle-scaffolded gem. However, when I run bundle exec gem install /path/to/my/gemfile then it installs OK, I guess because it sees my gems on the bundler-altered load path and decides that they are already installed. But then, when I try to run the executable, it fails because it can't find the dependencies when they are required. (Note that the executable has require bundler/setup as its first line after the shebang).
So I ask: what is a good way to deploy, with bundler, a command line application that depends on non-rubygems-hosted gems?
bundle exec sets up your load path correctly so that the gems are visible when you require bundler/setup. One option would be to always run your binary with bundle exec bin/hippo.
Something more suited to your purposes might be to run bundle install --standalone, which generates a bundle/bundler/setup.rb file within your project's directory. That file sets up load paths correctly for you, so you'd just need to do something like require_relative '../bundle/bundler/setup' from your binary instead of require 'bundler/setup'.
I want to use rbenv for setting ruby versions on a project per project basis. Otherwise, I want to use my default system ruby setup for everything else.
The problem I am having is the even though rbenv version returns system, gem command still uses the rbenv shim (.rbenv/shims/gem). So when I do gem environment my INSTALLATION DIRECTORY is '/Library/Ruby/Gems/1.8'. I would rather it remains ~/.gem/. I can see it still is that when I run /usr/bin/gem enviroment. I can't figure out where the rbenv shim gem is getting its settings from.
I've tried modifying my GEM_HOME both in my shell, and changing it in ~/.gemrc but that has no effect. I've been searching around with no luck. Hopefully someone here can help. Just some pointers to where the rbenv gem shim is pulling its values from would be helpful.
thanks
Since rbenv shims are pretty high in your PATH, their purpose is to intercept any invocation of ruby, gem, and similar, even if the currently selected Ruby version is "system". You shouldn't be worried about that.
Now, the default installation path for your system Ruby will always be /Library/Ruby/Gems/1.8. Here's my RBENV_VERSION=system gem env:
- GEM PATHS:
- /Library/Ruby/Gems/1.8
- /Users/mislav/.gem/ruby/1.8
- /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8
However, if you don't use sudo (and you shouldn't), gem install won't have write access to that directory, and will install the gems in the next writeable path, which is ~/.gem/ruby/1.8. That seems to be the behavior you want.