Skip to content

Instantly share code, notes, and snippets.

@DavidEGrayson
Last active October 27, 2020 18:40
Show Gist options
  • Save DavidEGrayson/42aaa74171e93bcefc18 to your computer and use it in GitHub Desktop.
Save DavidEGrayson/42aaa74171e93bcefc18 to your computer and use it in GitHub Desktop.
I am planning to post this to the RubyInstaller Google group at some point. Feedback is welcome! Help me make a convincing argument for MSYS2, while not stepping on the toes of the RubyInstaller team.

Hello.

I am wondering whether it would be possible to implement all the good things provided by the RubyInstaller project as packages for MSYS2. I am not an expert on RubyInstaller or MSYS2, but I think I understand the basic ideas, and there seems to be a lot of overlap in what the two projects provide. I think there could be very big advantages to using MSYS2 as the standard environment for running Ruby on Windows, mainly because of the package manager and the ease of compiling and installing libraries.

MSYS2 is a newer, more up-to-date alternative to MSYS. MSYS2 provides a Linux-like environment on Windows. You get bash, gcc, autotools, libtool, pkg-config, git, and a wide variety of other popular libraries and utilities. You get a package manager (pacman) to help you install these tools and keep them updated. Here is some more introductory information about MSYS2:

http://stackoverflow.com/a/25023611/28128 https://sourceforge.net/p/msys2/wiki/MSYS2%20introduction/

MSYS2 actually provides three different environments:

  1. The MSYS2 shell, which is like Cygwin, and provides emulation of POSIX. This environment is good for compiling and running software that was not designed for Windows. In this environment, gcc produces executables that depend on msys-2.0.dll.
  2. The MinGW-w64 Win64 shell, which adds mingw64 utilities (such as gcc) to the PATH and changes a few other environment variables. In this environment, gcc produces native 64-bit Windows executables that don't depend on msys-2.0.dll, but do depend on msvcrt.dll, which is part of Windows.
  3. The MinGW-w32 Win32 shell, which is like the Win64 shell except it is for compiling and using native Windows 32-bit programs.

The MSYS2 project already provides a Ruby package for each of the three environments, but the Ruby package for the MSYS2 environment has a lot of patches and is still on version 2.1.5. The win64 and win32 packages are more up-to-date (Ruby 2.2.1) and involve only three short patches. Here is the PKGBUILD script they use to build the native Windows Ruby packages in case you want to see what it's like to make a package:

https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-ruby/PKGBUILD

Here are some reasons I think MSYS2 would be good for Ruby:

Some gem authors tend to include copies of large C libraries inside their gems; for example the nokogiri gem and the libusb gem do this. I am not entirely sure why they are doing it, but I suspect it is because it can be hard to ensure that the C libraries they are depend on are installed, updated, and usable on the user's system. With MSYS2, the gem authors could just tell their users what MSYS2 package provides that library they need, and their extensions can automatically detect the shared library and use it. (Gem authors would still have the option to bundle libraries with their gems if that is the right choice for them.)

Another thing gem authors tend to do is to publish special versions of their gem for the x64-mingw32 and x86-mingw32 platforms which include precompiled .so files. I am not sure why they are doing this, but I suspect it is because maybe they don't want their users to need to install the RubyInstaller DevKit and set up their environment correctly. I think all or most of the tools provided by the DevKit are available from the MSYS2 package manager, so that should be less of a problem.

If gem authors stop bundling libraries with their gems and stop including precompiled binaries, it should mean that maintaining the gems becomes easier, and it should mean that users can more easily upgrade to a new version of Ruby or a new version of a C library used by a gem.

Setting up MSYS2 and Ruby will take more than one click for the user. But after about 10 or 15 minutes, they will have a very capable little system on their computer that can be used for many things besides Ruby. MSYS2 provides tons of useful software packages like git, gimp, ffmpeg, blender, QT Creator, vim, nano, wget, curl, emacs, python, perl, tar, and sqlite. You can see all the packages here:

https://github.com/Alexpux/MINGW-packages https://github.com/Alexpux/MSYS2-packages

So what would Ruby on MSYS2 actually look like? If you wan to try it out today, you can do this:

  1. Install MSYS2 from http://msys2.github.io/
  2. Update its packages to their latest versions following the steps here: https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
  3. Open the MinGW-w64 Win64 Shell, which can be found in your Start Menu, assuming you have a 64-bit computer.
  4. Run "pacman -S mingw-w64-x86_64-ruby" to install Ruby, which currently gives you Ruby 2.2.1. (Replace x86_64 with i686 if you are on a 32-bit computer.)
  5. Try running commands like "ruby", "gem", and "irb".

I was actually able to install gems sqlite3, ffi, and nokogiri in MSYS2 today. Some of them required a few minor fixes or special command-line arguments when installing. I tested that ffi actually works, but for the other two I only tested that I could Kernel#require them.

In the long run, most users should not use the Ruby package provided by MSYS2 because it only supports installing the latest version of Ruby. Instead, someone should maintain separate packages for each version of ruby which install that version into /mingw64/opt/rubies/ruby-2.x.x (64-bit) or /mingw32/opt/rubies/ruby-2.x.x (32-bit). Then chruby (or something like it) could be used to switch between these different versions of Ruby, setting the PATH, GEM_PATH, and GEM_HOME appropriately. These packages could be hosted on a special package server for Ruby users, and those users should be able to easily configure pacman to use that server.

In conclusion: MSYS2 makes Windows looks a lot like Linux, so Windows becomes less of a special case for people writing cross-platform software. I think Ruby users and gem authors could benefit a lot from the MSYS2 package manager and build tools. There is some overlap between MSYS2 and RubyInstaller, and it seems like joining forces could be beneficial. However, I am not an expert in either project and there could easily be some big things that I am overlooking, and there might be a lot of reasons for the status quo that I am unaware of.

--David Grayson

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment