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.
---
RubyInstaller does not install inside `Program Files`
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.
Proposed changes
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 `CommonAppData` for gem installation
- Consider that platforms (`i386-mingw32` and `x64-mingw32`) can coexist
- Ensure both `Ruby\bin` and theoretical `Gems\bin` directories are in the `PATH`
- 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, in all its versions and forms, is not an installer
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.
Proposed changes
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.
PS: The same contents of this email are as Markdown available on this gist:
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry