My normal install is C:\Ruby and C:\Ruby\bin is located in my windows
path.
If I do ruby -v (correct version shows)
If I do gem -v (correct version shows)
If I do gem list (correct list shows)
If I rename that folder to C:\Ruby.backup (to store as a backup folder)
the following applies if I go into the C:\Ruby.backup\bin and perform
the following:
If I do ruby -v (correct version shows)
If I do gem -v (it shows 3 versions less 1.3.1 instead of 1.3.4)
If I do gem list (it says its empty)
I think I might have figured out my own answer, possibly. In case this
is the wrong answer please post your own reply. But, I think the reason
why this is happening is because…
C:\Ruby\bin is in my windows path…
So even though I’m going into the C:\Ruby.backup\bin and performing gem
-v, it is looking in the C:\Ruby\bin path first and not the current
folder I’m in. I’m assuming it’s probably a windows order preference
with path variables taking precedence over current location.
So even though I’m going into the C:\Ruby.backup\bin and performing gem
-v, it is looking in the C:\Ruby\bin path first and not the current
folder I’m in. I’m assuming it’s probably a windows order preference
with path variables taking precedence over current location.
Interesting. For me if I have ruby’s in different locations but I cd
into the bin directory, gem -v, gem list report the gems for that
directory (i.e. it doesn’t work as yours does for some reason).
So even though I’m going into the C:\Ruby.backup\bin and performing gem
-v, it is looking in the C:\Ruby\bin path first and not the current
folder I’m in. I’m assuming it’s probably a windows order preference
with path variables taking precedence over current location.
Interesting. For me if I have ruby’s in different locations but I cd
into the bin directory, gem -v, gem list report the gems for that
directory (i.e. it doesn’t work as yours does for some reason).
-=r
Yeah, it was strange but I can confirm that the behavior did in fact
occur with Vista… go figure.
It also explains why sometimes I would have strange behavior when
running Rubygems with some of my apps.
RubyGems gem commands and Ruby ones are using @“ruby” to refer to the
executable.
So if there is a C:\Ruby\bin in the PATH (and is not your backup one),
will be used.
Also, it will try find “ruby” in the current directory and THEN in the
PATH.
Can you paste the output of “gem env” in both cases?
Thank you.
Hi Luis,
I tested with 3 different installations and you are correct. It listed
the gem sources properly for each of those folders.
When I confirmed the original earlier it happened while I was running
QSetup (a program installer) which housed a complete compiled version of
my 1.9.1 installation. I was testing whether or not the program
installer for my version would function properly. As it contains the
devkit and a lot of rubygems it was a huge undertaking. I completely
forgot that I was running the installer file and that it was copying
source into the C:\Ruby\bin folder. Therefore the gems had not finished
compiling and so it showed version 1.3.1. Once the installer completed,
the correct version was listed 1.3.4 and all gems showed up under the
list.
I cannot duplicate the issue I had earlier so I can only assume that it
had something to do with the additional installer running behind the
scenes.
All is well and I appreciate both of you responding to this. I just
wanted to make sure I understood how the processes were supposed to
work. You confirmed it for me nicely.
Ruby software (including RubyGems) use rbconfig.rb to figure out where
ruby lives so it can do things like call back into ruby correctly,
find other software, etc.
If you’re going to make a backup use real backup software or create an
archive of your ruby directory.
I have created a full one-click installer for windows that contains:
Ruby 1.9.1-p129 (ming compiled)
Gem 1.3.4
Rails 2.3.2 and all dependencies
MySql (compiled from binaries)
Sqlite3 (compiled from binaries)
Devkit
…
I’m not sure if anyone could use it or would want to host it. It’s an
installer.exe through QSetup and updates path variables for the install
location as well as associates .rb to ruby.
Ruby software (including RubyGems) use rbconfig.rb to figure out where
ruby lives so it can do things like call back into ruby correctly,
find other software, etc.
If you’re going to make a backup use real backup software or create an
archive of your ruby directory.
Hi Eric,
I’m not sure I follow you are maybe you are misunderstanding me. There
is no issue. Luis helped me understand how to determine the gem
environment and explained the path.
When I make a backup of any ruby installation (I keep 3 currently), I
keep them in the root directory and just append a date or backup to
them. There’s nothing wrong with doing this.
Whichever Ruby version I want to use remains in the same location and
same directory structure…
Example:
I have currently:
C:\Ruby (primary install and version I am using)
C:\Ruby_1.8.7 (backup version of 1.8.7 install)
C:\Ruby.backup (primary backup of the current version I am using)
If I decide to use Ruby 1.8.7, I rename my primary install folder
Ruby.OLD or whatever folder name I decide to use. Nothing has been
tampered with here. No moving of locations or inner movings of anything
within the base directory.
I then rename Ruby_1.8.7 back to Ruby and am able to use Ruby 187 as my
primary install.
All 3 installations work 100% with no issues. I have no problems doing
it this way. My path is set to C:\Ruby\bin so C:\Ruby is my primary
installation folder.
So, again, maybe I’m misunderstanding what you are saying here. Again,
I have no issues…
If I rename that folder to C:\Ruby.backup (to store as a backup
folder)
Do not do this, it breaks ruby.
Ruby software (including RubyGems) use rbconfig.rb to figure out where
ruby lives so it can do things like call back into ruby correctly,
find other software, etc.
Hello Eric.
Actually, Ruby on Windows is more dynamic and accepts relocation.
That’s how I’ve managed to build the exact same version of Ruby in a
sandboxed directory and properly relocate it during installation to C:
\Ruby.
This is done with a trick to rbconfig that removes the hardcoded PATH.
I’m not sure if anyone could use it or would want to host it. It’s an
installer.exe through QSetup and updates path variables for the install
location as well as associates .rb to ruby.
While a monolitic setup/installer sounds tempting, I’m against those.
Just to give a quick list of the issues with that:
It assumes all the users are insterested in all these components.
It bundles RDoc and RI elements, since it bundles installed gems.
It includes personalized stub files generated by RubyGems:
If you install Rake, it will generate a stub file for the location
where you installed it.
Updating individual components is going to be tricky.
For example: move from GCC3 to GCC4 or just one particular DLL.
Another critical point is: who compiled the binaries for Ruby? This is
important since if everybody going to use Ruby on Windows is going to
build it’s own Ruby version debugging is going to be impossible.
Of course, all the above points are my personal opinion, and can be
biased since I rather prefer minimalistic and more tailored versions
of the tools I use or develop.
I have created a full one-click installer for windows that contains:
Ruby 1.9.1-p129 (ming compiled)
Gem 1.3.4
Rails 2.3.2 and all dependencies
MySql (compiled from binaries)
Sqlite3 (compiled from binaries)
Devkit
…
I’m not sure if anyone could use it or would want to host it. It’s an
installer.exe through QSetup and updates path variables for the install
location as well as associates .rb to ruby.
Might be useful for some people. I could host it [however, as Luis
pointed out, it would deprive users of the pleasure of setting their own
up ]
@Luis I didn’t think it caused problems to just bundle up things
wantonly is that right?
I agree with both of you to some extent - installers are pre-defined and
don’t offer the ability to customize, plus you have to take everything
that is listed in the installer package.
In my case, I created the installer for someone that wants the latest
ruby 1.9.1 that works with windows and houses the latest mysql and
sqlite3 environments as well as fully working rails platform
(rspec-rails included). In the case of this particular installer, a
person could feasibly subtract from it but they wouldn’t have to worry
about having to find and compile binaries for more troublesome areas
(mysql, sqlite3, etc.).
I don’t have to include an installer… I could simply zip up what I
have.
My entire installation folder for Ruby is roughly 80 MB zipped because
it includes the devkit as well.
There are probably a lot of things that I don’t need to include but I’m
not certain what areas included should be classified as “need” and what
areas should be classified as “wants”.
I just wanted to save someone else from the hassle and frustration of
having to get up and running with a full ruby and rails environment for
windows using the latest windows. It took me roughly a full week to get
my entire setup configured, hehe.
Roger and Luis - you both have been so very helpful over that time
period as well. I’ve learned a lot from both of you.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
