Hello,
Over the past months I've been thinking on ways to improve current RubyInstaller experience for users -- including DevKit -- aiming to make it more Windows-friendly.
While RubyInstaller in its current form has fulfilled my personal needs, I acknowledge that, for newcomers or Windows-centric developers, its usage is problematic and sometimes cryptic.
Below are the common list of complaints I often hear (via Twitter rants, GitHub issues and personal hate emails delivered to my inbox).
I would appreciate your comments on such issues, specially if you had experiences with other tools that have found balance to solve those issues.
Also: installing inside a path with spaces.
The technicalities around this are big, ranging from UNIXism inherent to Ruby,
looks like mkmf (used to compile extensions inside gems), RubyGems and
Bundler, to name a few.
You can experience the same issues on Linux/OSX just by installing Ruby in a directory with spaces.
Ruby, RubyGems and also Bundler have improved in this area, but 3rd party gems might break due this.
Associated with it but no less important, is the nature of Program Files
and the need for elevation of privileges (UAC) dealing with it.
This forces most of all the users that had installed Ruby inside
Program Files to run all their commands as Administrators. We all
understand that such usage is not recommended.
While we cannot fix all the gems that do not properly handle path with spaces, we could attempt to put the basic foundation for those gems and make Ruby a better Windows citizen.
- Recommend installation inside
Program Files - No longer install gems along Ruby's structure
- Adjust RubyGems defaults to use
CommonAppDatafor gem installation - Consider that platforms (
i386-mingw32andx64-mingw32) can coexist - Ensure both
Ruby\binand theoreticalGems\bindirectories are in thePATH - Ensure Start Command Prompt with Ruby also uses those paths (for those with multiple versions)
Introducing those changes will allow installed gems be shared by different users, avoid the need for elevation of privileges during installation and last but not least, reusability across upgrades of Ruby.
As pointed by Rob Reynolds (ferventcoder), this will require some special permissions to be applied to this shared location so both services and users can access and write into this location.
Only drawback with this approach is compatibility with older (pre-Vista)
versions of Windows like XP or Server 2003, which uses path with spaces for
CommonAppData (not to mention Windows Server 2003 uses AllUsersProfile,
argh).
One last thing, there is only one issue with RubyGems, and is described in the following pull request:
DevKit installation experience has been the top complaint about RubyInstaller usability issues.
Not being an installer, not knowing which one matches the version of Ruby that was just installed, running cryptic commands in the command line and not knowing what are we doing (or how to interpret the output).
This is just a summary of the common complaints about it.
There are a few challenges around this and some compromises. Include the DevKit on each release of RubyInstaller will bump our installers from 16MB to 120MB.
Not only that, will promote duplication of the DevKit itself by duplicating the bytes transfered.
Instead of going that route, we should look into making the RubyInstaller offer you the option to install the Development Kit, which will download a defined package for that version of Ruby and proceed to install in a shared location (similar to gems perhaps).
If the compiler was already installed (due a previous installation), then no download and no installation is required.
At the time the Ruby package is generated, we can stamp the default configuration (like we do with RubyGems), to include the specific version of the DevKit required for this version.
We can attempt to load it and if is not found, then indicate about the issue and propose the next command to be executed to solve it.
For those who want to built a portable Ruby that includes DevKit, we can
prioritize lookup by checking a DevKit folder relative to Ruby\bin
directory and use that instead.
If they wanted to use a custom/different DevKit, they could load it via
devkitvars.bat and avoid the entire check/lookup described above.
If you reached this point, thank you.
Above was the list and my initial thoughts on what believe are changes that will improve this experience.
Please take your time to analyze it and let me know your thoughts.
Once again, thank you for your time, patience and interest in making Ruby for Windows a better experience for everybody.
Regards.