I've been using Middleman since a while, but very recently it is getting some issues in loading.
This is likely due to the coexistence of very old gems of the same type.
Have to say that I did follow some online suggestions, but haven't really got the full understanding. So ended up using rbenv for managing ruby then bundle to install the gems.
Now, have two project that for which I need to "reset" and install only the referenced gems into the local folder or somehow they don't conflict.
I can't figure out how to do it.
Using the rbenv -local I can change the local ruby version, but not sure how to move next.
Any help?
Thanks
I don't think you need rbenv or rvm for this, although their are good tools. To run a piece of code with just the gems you need, and the versions you specified in your Gemfile, run any command prefixed with bundle exec.
For example bundle exec middleman server.
Related
I am patching a script, and want to run code from a repo I manage that has patches.
The gem in question is not installed through a published gem but through a github link
When requiring any gem that is normally installed. The script works. But requiring any gem that is installed through a github link fails. Any suggestions?
If I understand the problem correctly, there are a few solutions:
Clone the gem that's only available via the github link, build the gem locally, install it. You should be able to require it
You might be able to manage the project with bundler and a Gemfile. Instructions here for the syntax. Bundler basically does what I suggested above, for you. I don't think gem can install a gem from a remote natively?
Would love to see some more clarification, and if you're using a Gemfile the relevant snippets
So the issue was I was running the script in question using ./bin/path/script
This will not work if the script includes github referenced gems, you need to prefix this with bundle exec which is not immediately obvious, given that when you use non-github referenced gems, it works fine without it.
Now running bundle exec ./bin/path/script will work for both, it's probably just better using that wherever possible.
I was trying to install Sinatra and I kept on getting this error: You don't have write permissions for the /Library/Ruby/Gems/2.0.0 directory
Thanks to "Installing gem or updating RubyGems fails with permissions error" I installed rbenv. I followed the guide and set my global ruby version, etc. but I continue to get the same error when I try to install gems. When I run gem environment the installation directory for RubyGems is still the system Ruby directory.
Should I update GEM_PATH? Since the rbenv guide doesn't mention anything about that, something makes me think that there is still a problem with my rbenv installation.
Can someone please help me figure this out?
You're not showing us the commands you're using but it smells like you're using sudo to install Sinatra. Don't do that with rbenv or RVM managed Rubies.
Just as in the linked question, using rbenv or RVM allows you have one or more Rubies in your user-space where you can modify them all you want. That means you don't need to use sudo, just use gem install ....
An alternate problem you could be having is you set your global Ruby to be system, which is the version installed by Apple for their use, and which you don't want to modify unless you understand why it's there and what they're using it for. IF you have to change it then sudo would be appropriate but, with rbenv or RVM managing Rubies in your user-space there's really no reason to.
Do NOT use chmod to change the ownership of the vendor installed gems; Again, that's for Apple's use so have fun with the local Rubies instead and leave Apple's alone.
In this case, I quit Terminal and upon reopening, things were working correctly. Probably a good thing to try if you're stuck and are sure you've followed instructions correctly. It's not explicitly mentioned in the material I read but I believe is a good practice in general.
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.
Apologies for the topic title, couldn't resist.
Basically, For no reason whatsoever apart from trying out different things. I want to implode RVM and try out rbenv. Nothing against RVM, just want to try different peoples software and try different things out.
I can get rid of RVM and install rbenv no problem. Could you guys confirm a few things for me.
Firstly, if I do the above, and then install a few different ruby versions. I know I can place a .ruby-version file in a projects root directory to specify a specific ruby version but then when I say gem install <gemname> I take it that is installed globally for that ruby version.
If I then use bundler per project to manage what gems are used and I specify a gem version, what happens if the version specified in the lock file is different to the currently installed version and what happens if it's vice versa?
I just need a bit of clarification on what's doing what in regards to ruby, versions, gems and their versions.
One of the (many) lovely things about rbenv is that you can so easily look right at your ruby installation to see what's going on. For example, on my machine I can open ~/.rbenv and there's versions containing my ruby installations, such as 1.9.3-p327. Opening that, I can keep drilling down to see my gems installed for that version of ruby (in ~/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems). It is then trivial to run gem list or gem install somegem and confirm that what's being affected is this very collection of gems - if this is the current ruby (set in rbenv global and starred in rbenv versions).
In short, everything about your system thinks that ruby means this version of ruby and that its library is this library.
For Bundler, you'll need to install rbenv-bundler. A nice tutorial (easily found with Google) is here: http://dan.carley.co/blog/2012/02/07/rbenv-and-bundler/
After a recent reinstallation of Ubuntu, I reinstalled RubyGems. The Ubuntu repository grabbed version 1.3.5. Later I found I need the latest version. So I installed the RubyGems update to get to version 1.3.7.
The trouble is, upon upgrading gem list returns only a small subset of all my originally installed gems. In the past, I've solved this by reinstalling all my gems following an upgrade, but this is troublesome and I hope to avoid this workaround now and in the future.
I tried adding an export GEM_HOME to my .bashrc file. It didn't work. gem list still doesn't list all my gems (even though I can find them on my computer in /var/lib/gems/1.8/gems. I also created a .gemrc yaml file and set the gemhome path. When I run gem env I can see that the home path is set, but still gem list doesn't return everything.
What's up with this?
This won't directly answer your question, but a lot of us use rvm to manage Ruby and gems. The benefit is it doesn't require us to mess with the system's Ruby installation and gems, leaving those alone for any OS routines needing a particular version of Ruby or a gem.
Since switching to rvm I've quit installing an updated version in /usr/bin/local too as rvm makes it so easy to keep my development versions separate from the system.
There are great reasons to tweak the system gems so I won't question why you might do so. I'm just tossing out the rvm thang as it might help solve your needs.