-
Notifications
You must be signed in to change notification settings - Fork 305
FAQ
- What are goals of this project?
- What Windows versions are currently supported?
- Should I install to C:\Program Files?
- Can I install both Ruby 1.8 and Ruby 1.9?
- How do I peform a silent install with the RubyInstaller?
- If I install both versions, is there some graceful way of selecting which version is active at a given time?
- Why are the installers so small?
- What happened to all those nice things that the original One-Click Installer (OCI) bundled in for us?
- Why do I have leftover files after uninstalling?
- Where are all the bundled goodies from the original (short)?
- Where are all the bundled goodies from the original (long)?
- Where is SciTE editor that was bundled before? I want it back!
- I want gem X to work right now!
- How do I uninstall the legacy DevKit?
- How do I upgrade the SFX DevKit when a new version becomes available?
- How should I configure MSysGit before contributing or trying to use the project build recipes?
- I’ve contacted the gem author but he/she can’t build me a Windows binary gem. What now?
- Why can’t I just download a binary Ruby distribution from the main ruby-lang site?
- Why should I use the RubyInstaller environment rather than downloading the free Microsoft tools and a binary Ruby distribution from the ruby-lang site?
- I think I’ve found a bug. Where do I submit it?
- Where do I go to contribute or make a suggestion?
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:
- Provide a easy to use Windows installer for quickly and painlessly installing a fully functioning baseline MRI Ruby environment on Windows platforms.
- Provide an optional development kit for those interested in building mswin32-compatible Ruby extensions natively on Windows platforms using a MSys/MinGW based toolchain.
- Provide a build environment via this project and complementary projects like rake-compiler to help developers easily build Ruby and Ruby C extensions from source code.
- Add value to the growing community of Windows-based Ruby developers by providing a place that summarizes the hard won lessons and issues with building Ruby and Ruby C extensions natively on Windows.
A: Currently RubyInstaller explicitly supports Windows XP, Windows Vista, and Windows 7 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: No. Longer answer in process.
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"# 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"
Q: If I install both versions, is there some graceful way of selecting which version is active at a given time (e.g., which ruby.exe is invoked, which irb.bat is called, etc.)?
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.
Q: When I uninstalled the RubyInstaller, I saw that there were some leftover files in the installation directory. Did the RubyInstaller uninstall incorrectly? Did I do something wrong? Should I file a bug?
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 treetop sinatra haml amalgalite 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.
Q: What happened to all those nice things that the original One-Click Installer (OCI) bundled in for us?
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 :)
Q: OK, I get the short answer. But I really want to know why on earth you didn’t bundle all the goodies that the original OCI included?
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 are providing 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.
We plan to offer the DevKit as a gem in the near future. Please stay tuned for more info.
For now, the Development Kit can be downloaded from RubyInstaller Downloads
Like you, other would like other editor instead of SciTE, or event better no editor at all. The approach of RubyInstaller project is not dictate any preference over users or usage, giving freedom to users 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 devkit-3.4.5r3-20091110.7z extracted 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.
A typical update can be as simple as:
1. Open up the directory where you originally installed the DevKit. Let’s call that <DEVKIT_INSTALL_DIR>
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 etc and home subdirectories.
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 (devkit.rb and 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 working on creating a DevKit installer that’s just as easy to use as the RubyInstaller. 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: Ensure your global configuration contains at least the following settings, ensure cygwin is not on your PATH, and no strange variables in your .bashrc or .bash_profile hidden in your HOME directory.
C:\>git config --global --list
core.autocrlf=false
push.default=currentQ: I’ve tried to contact the gem author and he/she said doesn’t have a Windows-based system on which to build a binary gem for me.
A: That’s understandable. We can’t force everyone to get a Windows license, a virtual machine and take the time to develop and release Windows binaries of those 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.
http://wiki.github.com/luislavena/rake-compiler/projects-using-rake-compiler
Q: I understand the project goals, but why can’t I simply download the latest MRI binary distributions for Windows from ruby-lang.org?
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.
Q: Now that Microsoft is providing its free Visual C++ Express editions and including build tools such as cl, link, nmake, etc as part of the Windows SDK (as of mid-2009), why can’t I just download the MRI binary and Visual C++ Express and start developing? Why would I want a MinGW-based implementation?
A: in process…
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:
http://groups.google.com/group/rubyinstaller
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 :-)