Rip for Windows
When I first found a post about Rip I was eager to try it. Since most of the time I work on MS Windows platform it was natural to try it there, but Rip concept is Linux oriented and it couldn’t be installed and used on Windows. Going back to the old, good Linux gave me a feeling what Rip is and how it works, and I’ve decided to try to fix it as soon as I find some spare time. Additional motivation was a fact that Ruby installer for windows RC1 is about to be released and that’s one more project that I participate in, from time to time.
So here it is. If you are willing to try Rip on Windows just download gem and install it. Rip is in development alpha state, therefore this Windows version can be marked as development pre-alpha.
Although Rip environments can be created, deleted and gems can be installed, there are features that do not work. Complete Windows specific code is on my fork on Github. A reason why I wanted to put this version available so early is mostly the same as you can see on the Rip homepage – need for suggestions, ideas, patches and tests.
Here comes short explanation of Windows specific part. Rip on Linux uses symbolic link that points to the active environment. Unfortunately such a feature is not available on Windows. Although on Vista and Windows 7 mklink can be used, this command requires administrative privileges. It can be disabled through Local Security Policy settings, but that would be too much work just to get Rip working on Windows. Therefore I’ve decided to alter environment variables when Rip environment is created or changed.
This approach has its own drawbacks. If user has more command prompts opened at the same time and Rip environment is changed in one of them, this change will not be visible in others. Cause of this is in the way command prompt is implemented. Namely it doesn’t handle WM_SETTINGCHANGE broadcast message. I really do not understand why MS developers didn’t implement this.
Main consequence of such command prompt implementation on Windows is that Rip has to change environment variables in two stages. First stage changes environment for command prompt where Rip command is executed. This change is done by calling batch file where variables are set. The second stage changes values in the registry. Variables are set in a user part of registry (HKEY_CURRENT_USER\Environment) and broadcast message is sent so other applications (such as Explorer) can update their environment which causes newly opened command prompts to pick up new environment.
At the end what are problems you could expect if you install Rip. I haven’t tested all Rip commands mostly because I was focused on basic functionality – Rip installation, creating and switching between Rip environments and installing packages in active one. Most likely some of commands will fail. In addition gems that have to build shared libraries will fail even if you have RubyInstaller DevKit installed. Moreover even if gem has binaries built for mingw32, Rip will invoke build procedure and will report that gem is not correctly installed and you will not be able to uninstall it from Rip environment later. Actually such gem is installed and can be used. One such example is Luis Lavena’s win32console gem. Even if build fails and Rip reports that gem is not correctly installed all necessary files are actually present in Rip environment and you will be able to run tests.
I’m still trying to find out how to determine whether gem needs to be built or it already has binaries. As soon as I find out this I’ll fix this part too. That’s all for now and happy Ripping.
