29 August 2006

Problems with RubyGems and Platform Specific Gems

Something that at least a few of us are annoyed with is the case where there is a ruby version, as well as a platform specific version of a gem. Good examples are mysql and mongrel, amongst others. I see a couple of issues here, but the crux of the issue is that this kills the ability to automate (non-interactively) installation.

First, why should the system even offer the win32 version of the gem to me if I'm not using a Windows machine? Fixing that would fix the problem for many people.

But, let's say you are doing multi-platform development, and in particular include in that Windows. I think RubyGems ought to be updated so that you can specify a platform variant when you install a gem, much as you can specify a version. This way, your automation script could simply specify the one it wanted, given the platform it was running on.

The other thing I'm wondering about is what solutions people have in terms of being able to freeze your gems, but where you have gems that have native code, and where you work on multiple platforms. This must be extremely common in the Rails world, where it seems the standard developers machine is MacOS X, and deployment servers are typically some UNIX flavor. Also, I've yet to try it, but I presume things don't behave well if you freeze gems on one platform and then go to another - I assume it freezes gems that include native code?

Anyone have solutions to these issues?

technorati tags: