A: The RubyInstaller project aims to provide developers working on Windows systems with a quick and easy way to begin developing with Ruby using an MRI-based (Matz’s Ruby Implementation) environment while enabling enhancements through Ruby’s standard RubyGems packaging system.
Specifically, the goals of the RubyInstaller are:
A: Currently RubyInstaller explicitly supports Windows XP, Windows Vista, Windows 7, and Windows 8 in both 32 and 64-bit flavors. By “explicit” we mean that we accept bugs discovered on those versions, we perform testing of the installer on those versions, and we use code that supports those versions. This doesn’t mean that RubyInstaller may not work on other Windows flavors, it just means that we’ve had to focus our resources on supporting the more mainstream Windows versions.
A: The binary packages for Windows found on ruby-lang.org lack several key components, such as OpenSSL, Zlib and Readline, which results in a broken experience for users trying install these binary distributions out-of-the-box. To compound the issue, other extensions are built-in, but lack essential bindings such as Tk and gdbm.
Locating and installing the correct versions of these missing components can be tricky; RubyInstaller seeks to alleviate these difficulties and make the installation process dead-simple by providing everything you need to get started in one straightforward installation package.
require 'rbconfig' if RbConfig::CONFIG['host_os'] =~ /mingw|mswin/ # running on Windows end
A: Yes. By using the RubyInstaller, Ruby 1.8 will be installed by default to
C:\Ruby, while 1.9 will be installed to
C:\Ruby19. This is by design as Ruby 1.8 and 1.9 offer a different API that may interfere with some RubyGems.
A: The RubyInstaller currently uses Inno Setup which allows two levels of silent installation (silent with just an install progress window, or very silent without even an install progress window) to be selected using either the /silent or /verysilent command line options.
When performing silent installations, you often want to specify where to install the Ruby environment and whether the RubyInstaller should associate .RB/.RBW files and update your PATH environment variable to use the newly installed Ruby.
While the Inno Setup Help provides the details, an example shows how easy it is:
# silent install to default dir with no file associations nor PATH update c:\>rubyinstaller.exe /silent
# silent install to custom dir with no file associations nor PATH update c:\>rubyinstaller.exe /silent /dir="e:\my_test_ruby"
# silent install to default dir with private Tcl/Tk library installation c:\>rubyinstaller.exe /silent /tasks=addtk
# use Japanese installer to silently install to default dir with private Tcl/Tk, # file associations, and PATH update c:\>rubyinstaller.exe /silent /lang=ja /tasks="addtk,assocfiles,modpath"
# very silent install to default dir with file associations but no PATH update c:\>rubyinstaller.exe /verysilent /tasks=assocfiles
# very silent install to custom dir with file associations and PATH update c:\>rubyinstaller.exe /verysilent /dir="d:\rubyABC" /tasks="assocfiles,modpath"
A: Pik is excellent for this coordination—check it out
A: Because the installers contain just the baseline Ruby environment, the RubyGems package system, key DLLs required to ensure a usable baseline Ruby installation, and important Ruby documentation. This baseline Ruby installation enables you to quickly begin developing in Ruby and to quickly begin using existing Ruby applications while enabling you to customize your Ruby environment for your unique needs.
A: Not to worry, you did nothing wrong and there’s no need to file a bug report. The RubyInstaller uninstalled correctly as we built the RubyInstaller to uninstall only the files it originally installed. Any leftover files in the installation directory are most likely due to customizations you made to your RubyInstaller-provided Ruby environment. We do not want the RubyInstaller assuming it should delete any of your customizations.
For example, imagine that you’ve modified your Ruby installation with a few of your favorite RubyGems via
gem install rake citrus sinatra haml nokogiri sequel and you’ve also created a super cool executable Ruby script that automates away much of your daily monkey work. You’ve also just found out that a new version of the RubyInstaller is available with the latest and greatest Ruby bug fixes and you’d like to upgrade it, but do not want to go through the hassle of reinstalling all of your RubyGems or losing your super cool Ruby automation script.
Since the RubyInstaller does not blindly delete everything in the RubyInstaller install directory, all of your RubyGems and custom files that you configured for your Ruby environment with remain after the RubyInstaller uninstalls. The RubyInstaller will uninstall itself, but not your customizations. We think you would be very unhappy if the RubyInstaller assumed it could delete itself and everything you worked so hard to customize. We believe you’re the only one who knows best when deciding how you to manage your Ruby customizations.
However, if you discover that RubyInstaller is not behaving as described, please let us know via the mailing list or the bug tracker listed later in the FAQ.
A: The not-so-short answer is that while many of the original packages are no longer pre-installed by the new RubyInstaller, we believe we’ve integrated just the right amount of core features while enabling you to easily add additional capabilities that you may need by utilizing the proven RubyGems packaging system. As always, there’s a longer answer :)
A: This version of Ruby has been built with MinGW (GCC), not the 12 year old compiler in Visual Studio version (VC6) used by the original One-Click Installer.
In the original installers, lot of gems and packages were bundled. Some of those packages have not been updated in years, some of the packages do not appear to regularly maintained, and some of the packages lack the tests and testing tools needed to ensure they work as expected with this version of Ruby.
Instead of investing the RubyInstaller Team’s limited time on fixing those packages, we decided to focus on improving the overall user experience on Windows-based systems by providing a rock-solid Ruby baseline installation from which you can build upon based upon your unique needs.
We acknowledge that some gems will not work, and some others will not install. That’s why we provide a Development Kit (DevKit) to ease the process of rebuilding the gems for your Ruby installation. The DevKit contains the needed tools to compile or successfully install gems that are not ready for this version of Ruby.
The Development Kit can be downloaded from RubyInstaller Downloads
A: Like you, some users would like RubyInstaller to bundle SciTE, other users might want some other editor, and still others no editor at all. The approach of the RubyInstaller project is to not dictate any preference over users or usage, giving users the freedom to choose what tool they want to work with.
As RubyInstaller do not try to take over user’s installation, we don’t want to take over user’s preference for editors. You can refer to Windows Friendly Editors for instructions on how to use RubyInstaller with different editors, including SciTE.
If you want to read Luis Lavena’s personal statement about this decision, please read this message at RubyInstaller Google group.
A: If those gems don’t work out of the box with DevKit installed, please contact the gem author and make them aware of this compatibility issue with their gem.
A: The legacy Devkit
gcc.bat, make.bat, sh.bat batch helper scripts to a specific Ruby installation into the Ruby’s
<RUBY_INSTALL_DIR>\bin and its core files into
<RUBY_INSTALL_DIR>\devkit. To uninstall the legacy DevKit, simply delete the batch helper scripts and the
<RUBY_INSTALL_DIR>\devkit subdirectory and double check that your
PATH environment variable does not contain any references to what you deleted.
A: The self-extracting executable (SFX) DevKit version does not require one to separately download the 7-Zip tool in order to install it. Simply download the executable, double-click, choose an install directory and extract. While you’ll need to do a bit of configuration, installation is straight forward. However, as the SFX is not a full-featured installer, upgrading the SFX DevKit to a newer version requires some manual work, but not too much. NOTE: the SFX is really a 7-Zip archive with a bit of embedded magic. If you already have 7-Zip installed, you can simply right-click it and extract it’s contents as you would a normal 7z archive.
A typical update can be as simple as:
1. Open up the directory where you originally installed the DevKit. Let’s call that
2. Delete all the
<DEVKIT_INSTALL_DIR> subdirectories and files except for
config.yml. If you’ve made any customizations to the MSYS shell you may also want to keep files in the
3. Extract the new SFX DevKit into the same
<DEVKIT_INSTALL_DIR> that you just cleaned up.
4. Review your
config.yml file to ensure it contains the root directories of all the installed Rubies you want enhanced to use the DevKit.
5. From a Command Prompt,
cd into the
<DEVKIT_INSTALL_DIR> directory and run
ruby dk.rb install --force. This will cause all your installed Rubies listed in
config.yml to use the updated SFX DevKit when building native gems and update the DevKit’s helper scripts (
operating_system.rb) with any new functionality. For safety, the original helper scripts are timestamp archived beside the new helper scripts. It’s always a good idea to review the two versions (and potentially make modifications) to ensure configuration specific to your system still works as expected.
A: Glad to hear you like it! We’re started the work to create a DevKit installer that’s just as easy to use as the RubyInstaller. However, there hasn’t been much demand for the DevKit installer. However, if you’d like to help speed things along, drop by the RubyInstaller Google Group and let us know how you’d like to help.
A: Both the .exe installers and .7z archives include the libraries required to develop GUI applications in Ruby using the integrated Tcl/Tk toolkit. The Tcl/Tk toolkit is integrated with the RubyInstaller in such a way so as to not conflict with existing Tcl/Tk installations (e.g. – ActiveState’s ActiveTcl) you may have installed on your system.
If you install Ruby using the .exe installers, the Tcl/Tk installation is optional. Simply opt-in by selecting a checkbox in the GUI or specify the addtk task if installing silently from the command line. If you don’t want Tcl/Tk support, there’s nothing extra you need to do.
If you install Ruby by extracting from the .7z archives, Tcl/Tk support is already integrated and ready to use without further configuration from you.
A: in process
A: No. The (optional) Tcl/Tk support is private to the RubyInstaller and will not conflict with an existing Tcl/Tk installation you may already have installed. If the RubyInstaller’s private copy does conflict, we’ve overlooked something and it’s a bug that must be fixed. Please let us know ASAP if this ever happens.
A: No. in process
A: While Google is your friend for this one, this Ruby Tk tutorial is a fantastic first step. As the installers and archives include the required Tcl/Tk libraries and Ruby’s Tk extension, you can skip the tutorial’s installation section and jump directly to the examples.
A: Absolutely. The Ruby-GNOME2 project provides a 1.8/1.9 native Rubygem for RubyInstaller environments that includes all required dependencies. To get started simply type
gem install gtk2 and start building your next GUI in Ruby! Check out their tutorial for more info.
A: Ensure your global configuration contains at least the following settings, ensure cygwin is not on your
PATH, and no strange variables in your
.bash_profile hidden in your
C:\>git config --global --list core.autocrlf=false push.default=current
A: By default, all RubyInstaller downloads are already GDB-friendly as they are built with the
-g option. For performance reasons they’re also optimized with the
-O3 option that can interfere with debugging. For intense debugging sessions, your Ruby should be built with
-ggdb3 -O0 and the easiest way to do this is to override the default build configuration by placing a
.rb file in the
override subdirectory of your RubyInstaller clone similar to the following. Finally, run something similar to
rake ruby19 debug_build=1 and look in the
sandbox/ruby19_mingw subdir for your new GDB-friendlier RubyInstaller build.
# file: override/debug_build.rb if ENV['DEBUG_BUILD'] then puts '[INFO] Generating debug optimized build...'
# enable debug 1.9.x builds RubyInstaller::Ruby19.configure_options << "optflags='-O0'" RubyInstaller::Ruby19.configure_options << "debugflags='-ggdb3'" end
A: That’s understandable. Not all developers have the means to afford a Windows license, and even among those who do, not all have (or are willing to take) the time to set up a virtual machine and develop Windows binaries for their gems.
For that purpose, the RubyInstaller Team created the “rake-compiler” tool available from the following sites:
With this tool the gem authors can compile and build gems for Windows users from Linux or Mac OSX operating systems.
There are already plenty of other gem authors using rake-compiler, so please give the following link to the gem author so they can take a look to those implementations for examples of how they might use rake-compiler to update their gems.
A: Unfortunately, a lot of popular Ruby projects out there still assume that the underlying operating system is going to be a GNU-ish one such as provided by MinGW, so this is still the way to go if you need stable, well-supported code. But if you are a trail-blazing sort and like getting your hands dirty, your help on the “mswin” side of things could make a big difference!
A: Please submit any bugs you find to the Issues tracker at GitHub:
A: We would love to hear from you! Documentation updates, patches, tasty graphics creations, how you think we can improve the process, and anything else you would like to contribute are all really appreciated, and requested :)
First, take a look at our How to Contribute page, then join us at our rubyinstaller Google Group:
Please introduce yourself and share with us what you would like to see improved, implemented or fixed. We are a friendly bunch of users and developers who are deeply passionate about running Ruby on Windows :-)