It’s not really a secret that Ruby is not best friends with Windows. You often encounter gems that just won’t install or if they install, will not run as expected. Among those gems are mysql, eventmachine, nokogiri or, in my latest project, curb. I think this could be improved a lot with just a few changes.
The people over at RubyInstaller are doing a terrific job at making Ruby available on Windows, but they obviously can’t solve all the problems by themselves. If it weren’t for them, I’d probably have given up on Ruby a long time ago. (Bonus Tip: A few weeks back, Luis Lavena appeared on the Ruby Rogues Podcast).
There is a line somewhere between things that are just sloppy and things that intrinsically can’t work. Unicorn, for example, is based heavily around the concept of forks – which just don’t exist on windows. I don’t blame them for choosing this implementation. [edited]Sometimes, the problem is in an upstream C-library just is not available on windows[/edited]. At the the other end of the spectrum are simple fixes that don’t get merged for almost two years, or bug reports that are shrugged off with “I recommend […] installing your favorite linux OS” by the gem authors.
It has gotten to a point that i will google the most common problems before i even start to look into a new gem. Going over a readme is not enough, even gems that mention Windows sometimes break when copy&pasting the first few lines of example code. This is just ridiculous. It implies that failing is the default state, rather than the exception.
Curiously, this is not a problem with Ruby itself. Ruby itself works great on Windows. It’s the gem install death by a thousand papercuts that ruin an otherwise beautiful language, ecosystem and great community.
If you are part of that community, I’d love to ask you to not marginalize the windows users. You certainly don’t need to buy a Windows machine or license, but merging code with windows fixes early will go a long way. Also you might consider creating a windows-tag on your bugtracker, if you have frequent (or long standing) issues on windows. If your gem needs to compile native extensions, mentioning the DevKit in your readme will help newbies tremendously. If you can, or if someone contributes them, you could offer precompiled gems for Windows.
[Edit 2]Mike Dalessio suggested on Twitter, that Windows users themselves should get more involved. He is absolutely right, and I should have included this important point right from the start. Personally, I think it should be common courtesy to give back to a project one is using, so I feel bad about not explicitly mentioning it.[/Edit 2]
[Edit 3 2015-04-07]Ruby 2.2.1p85 is now out on windows (since the beginning of march). A lot of gems that went the extra mile to release pre-built gems are now broken. So far, on this list: net-ssh, ffi and hitimes. It should be noted that Windows folks at least need to report bugs to ever get them fixed. Mentioning them on StackOverflow will usually NOT get them fixed. Also, Ruby itself seems to ship with a bug in globbing behaviour that breaks pretty much every simple setup of test suites and the like. Supplemental: This was fixed in Ruby 2.2.2[/Edit 3]
[Edit 4 2015-05-31]Nokogiri does also not yet support Ruby 2.2. This issue has been open for nearly three months, now.[/Edit 4]
[Edit 5 2015-06-15]wdm, required by the listen gem on windows, does also not work with ruby 2.2 on windows. And i recently had to find out that rugged does not easily install on windows, as well.[/edit 5]
[Edit 6 2015-07]bcrypt won’t run on ruby 2.2.2. With pretty much the same error it threw when it did not work with 2.1.[/Edit 6]
[Edit 7 2015-10]I just learned that sqlite3 is broken on windows with ruby 2.2, which is especially problematic for newbies trying to get into rails development. The issue is now half a year old, and for the last three months, a promising pull request is not being merged or commented on.[/edit 7]
[edit 8 2016-03]bcrypt can now be installed on ruby 2.2(.4) without workaround. Eleven months after the bugreport.[/edit]
I will probably get a lot of heat and comments like “you should switch to Mac OS”, or DHH’s famous “If you don’t care enough about your tools to get the best …” (which has been commented on beautifully at coding horror). Let me preempt those by saying: That’s not the point. I care about my Tools and I’m perfectly capable of using Linux or Mac OS. Currently my choice of (Desktop-)OS is Windows. Ruby alone will not change this.
If you have a problem with Nokogiri on windows, why haven’t you filed a bug report? We work hard to support Windows on Team Nokogiri and quite frankly posts like this that imply we are “sloppy” are disheartening and discouraging.
I have been affected by the missing support for x64 for about a year. To this day, i use Ruby in 32 bits, because a lot of other gems have had similar problems. This falls more on the “it intrinsically can’t work” side of the spectrum.
I did not include upstream library problems in my blogpost. I fixed that, and I’m sorry that I implied the nokogiri team as sloppy. That was not intended. Nokogiri is one of the most useful libraries out there, which is used so widely (and has rightfully become the de-facto standard) that problems with it hurt just so much more.
I also often encounter this pattern:
* Bug gets opened for a problem on windows
* The bug is closed in favor of a more general ticket
* The general ticket is closed when the problem is solved for Mac OS and/or Linux
* The problem will be resolved on windows a lot later, if ever.
Hey Claudius,
First let me stand and clap! you’ve nailed it.
Sometimes with small changes you can achieve amazing things, in this case, avoid frustrations and make developers happy.
Nice post. Thanks for taking the time to write it.
Best.
To prevent any misunderstandings: I had quite a blast using MSVC (and also some older obscure Windows IDEs), this reply is not meant to imply that Windows isn’t a good system to build software on! :)
In cases where the build really fails because of OS differences/limitations it’s obvious that that’s not sloppiness (as you mentioned in the unicorn example).
So in all other cases, this is a problem of actually building the external gem. Which, in turn, is heavily dependent on the underlying build system.
Note that gems using external libraries are dependent on the 3rd-party library correctly publishing it’s header/library files.
If that’s not the case, there’s often no meaningful solution to get it consistently compiling on all machines.
Building a gem with external dependencies is often done via mkmf.rb (AKA extconf.rb), and if you take a peek into a typical extconf, you’ll see a find_header() or find_library() call in there, which will scrape some common library paths for the header files.
Sometimes you’ll find typical MacOS-specific header locations added to this search in an extconf.rb.
But with Windows, the problem is that there’s no standardized location for header files to add there. Also, there’s no standardized ldconf mechanism where your library could just register with the system to publish it’s custom path.
Windows has never been a system where you could generically include external libraries without supplying the path where you installed them manually (I dev’ed on Windows for a decade, and it was always a pain when 3rd party was external to a project and not part of windows framework/compiler libs).
There’s a possible way around this: many (but not all) libraries have a configuration utility for this. Let’s take the curb gem as an example: it tries to call the executable ‘curl-config’ to determine the custom path.
This would solve the Windows path problem, but:
– you have to actually install the library before trying to build the gem (it’s not always obvious what external dependencies a gem might have!)
– it has to find the curl-config utility in the path (not all library installations add themselves to the PATH in windows)
– the -config has to actually exist (which is not the case for every single library)
– the config utility is often intended for configuring the gcc compiler, and might not be working correctly under windows
To stay with the curl-config example, here’s an (outdated) mailing list post where the answer’s just “meh, why would you need this in windows???” http://curl.haxx.se/mail/lib-2007-10/0036.html
Something like this is 3rd-party sloppiness, not Gem developer sloppiness!
The curb gem developer really did take care to ensure a smooth build experience: he actually warns when the library is not installed, and he tries to ask the library for custom paths. Trying out standard paths and using the config util is really the most he can do in an extconf.rb/Makefile context.
It’s not the Gem developer’s “sloppiness” that’s responsible here, but Windows not being a standardized “just fire up the compiler and the Makefile will do the rest”-System – and, you might argue, the 3rd party library developer/porter’s sloppiness (not supplying an installer, not adding the library to the path, not maintaining the compiler config tool for Windows, etc.).
And, maybe mkmf.rb not being the best solution overall – but that’s a completely different discussion (google it for some really good reads).
Cheers,
codegourmet
One thing that’s definitely missing: omitting Windows install instructions.
If you can find instructions for your gem in 100 different stackoverflow posts, it might be time to update your gem’s README.md
Also, treating Windows-tickets in the issues list as second-class doesn’t make any sense.
in the case of curb, these six lines would make most of the pain go away.
And yes: any and every windows developer who has that problem should have opened that pull request.