Devkit not added to path

[Zuhaib Ali]

I have to manually add the devkit bin directory to PATH in Windows. The drawback is that when I switch ruby versions, I have to update the PATH env variable for the new devit/bin directory too.

[Jon]

If you're using the RubyInstaller DevKit as a minimal toolchain for building native gems, I think the issue may be your configuration or usage.

If you've properly installed the DevKit (e.g. - create a config.yml and run ruby dk.rb install) you never need to add the DevKit dirs to your PATH in order to build native gems. Back in 2010 when I wrote the DevKit's dk.rb install script I made it create a RubyGems plugin that automagically adds (temporarily for just the gem build) the DevKit to your PATH everytime you tried to install or upgrade a native gem.

For example, on my system for ruby 2.1 the generated RubyGems plugin lives in C:\Apps\rubies\ruby-2.1\lib\ruby\2.1.0\rubygems\defaults\operating_system.rb and looks like

# :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage
Gem.pre_install do |gem_installer|
  load 'devkit.rb' unless gem_installer.spec.extensions.empty?
end
# :DK-END:

which references the devkit.rb file living in C:\Apps\rubies\ruby-2.1\lib\ruby\site_ruby\devkit.rb that looks like

# enable RubyInstaller DevKit usage as a vendorable helper library
unless ENV['PATH'].include?('C:\\DevKit-x32-4.9.0\\mingw\\bin') then
  phrase = 'Temporarily enhancing PATH to include DevKit...'
  if defined?(Gem)
    Gem.ui.say(phrase) if Gem.configuration.verbose
  else
    puts phrase
  end
  puts "Prepending ENV['PATH'] to include DevKit..." if $DEBUG
  ENV['PATH'] = 'C:\\DevKit-x32-4.9.0\\bin;C:\\DevKit-x32-4.9.0\\mingw\\bin;' + ENV['PATH']
end
ENV['RI_DEVKIT'] = 'C:\\DevKit-x32-4.9.0'
ENV['CC'] = 'gcc'
ENV['CXX'] = 'g++'
ENV['CPP'] = 'cpp'

The above locations are different on for my ruby 2.0 install with a 4.8.2 based DevKit because I had upgraded RubyGems from it's default value. The concepts are still the same.

So, with the above setup, I can do things like the following in which I upgrade the native oj gem via uru and have different DevKit versions automagically brought on to PATH dependent upon which ruby install is being upgraded. In this example neither the 4.8.2 nor the 4.9.0 DevKit bin dirs have been manually added to my PATH. The RubyGems plugin does that for each install of oj.

C:\>uru gem up oj

ruby 2.1.2p93 (2014-05-06 revision 45833) [i386-mingw32]

Updating installed gems
Updating oj
Fetching: oj-2.9.0.gem (100%)
Temporarily enhancing PATH to include DevKit...
Building native extensions.  This could take a while...
Successfully installed oj-2.9.0
Gems updated: oj

ruby 2.0.0p477 (2014-04-30 revision 45762) [i386-mingw32]

Updating installed gems
Updating oj
Fetching: oj-2.9.0.gem (100%)
Temporarily enhancing PATH to include DevKit...
Building native extensions.  This could take a while...
Successfully installed oj-2.9.0
Gems updated: oj

jruby 1.7.12 (1.9.3p392) 2014-04-15 643e292 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_05-b13
+indy [Windows 8.1-amd64]

io/console not supported; tty will not be manipulated
Updating installed gems
Nothing to update


C:\>uru gem clean

ruby 2.1.2p93 (2014-05-06 revision 45833) [i386-mingw32]

Cleaning up installed gems...
Attempting to uninstall oj-2.8.1
Successfully uninstalled oj-2.8.1
Clean Up Complete

ruby 2.0.0p477 (2014-04-30 revision 45762) [i386-mingw32]

Cleaning up installed gems...
Attempting to uninstall oj-2.8.1
Successfully uninstalled oj-2.8.1
Clean Up Complete

jruby 1.7.12 (1.9.3p392) 2014-04-15 643e292 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_05-b13
+indy [Windows 8.1-amd64]

io/console not supported; tty will not be manipulated
Cleaning up installed gems...
Clean Up Complete

See if installing the DevKit as per the above and using uru as I've described works for you. If not, summarize how you'd like to use them and we'll what makes sense to do.

[Zuhaib Ali]

Indeed the PATH is automagically enhanced during gem compilation. However, the same is not true when some rails gems rely on the devkit binaries in runtime, e.g devkit comes with a file.exe binary which is a port from unix-like OS'es and allows gems to use it on Windows systems which do not have it by default. In that case, I'll need to have added the devkit/bin manually to PATH (because no automatic enhancement there).

So far I'm having to switch between Ruby 1.9.3 and 2.0.0 and such runtime binaries work fine across both rubies so I do not actually have to switch PATH frequently. But that seems to me less than ideal... I thought maybe the moment we type uru 193 , path is enhanced to include the relevant devkit already.

[Jon]

Since uru targets windows, linux, and osx systems I can't hardcode assumptions about the devkit nor can I assume a canonical devkit install location.

I'm a bit surprised that some rails gems rely on devkit exes at runtime. Would you spin me up on the specific gems that do this? Maybe we can find something workable with uru.

[Zuhaib Ali]

I was surprised too. I discovered yesterday while using the popular paperclip gem without explicitly having added devkit/bin to PATH. It wouldn't work. Here are the offending lines:

https://github.com/thoughtbot/paperclip/blob/master/lib/paperclip/media_type_spoof_detector.rb#L63

It is relying on the "file" binary in devkit if the user is on Windows. On Unix-ilke systems it doesn't because they already have this file binary at OS-level.

[Jon]

I have a potential uru usage "fix" for you. As uru never modifies your base PATH and only prepends values to it, try putting your devkit bindir on PATH before you first use uru. As uru switches your PATH, each ruby will be prepended in turn but your devkit bindir should remain. Try it and everytime you switch to a new ruby type set path to see what I mean.

I could rant for awhile on how paperclip and other gems only utilizing OS-specific capabilities without fallbacks are doing multi-platform Ruby support wrong and shooting Ruby in the foot. But I'm not going to. It could be a simple oversight on the paperclip devs part, or a conscious tradeoff they've made, or simply inexperienced coding. Regardless, this is a paperclip bug.

It's this type of behavior that makes make MRI on Windows less viable and, long-term, increases the chances of MRI becoming a nix-only solution for all intents and purposes. For every gem like oj, nokogiri, and psych (notice all are native gems) in which the devs do the hard work to keep the gem multi-platform, it's appalling to see a (non-native?) gem like paperclip force itself into a nix-specific corner. So much for not ranting.

I dislike the idea of putting the devkit bindir on PATH to workaround the paperclip bug. But if you do it before you first use uru, you should be able to switch rubies and have the devkit artifacts remain on PATH. If this works for you, please close this issue out.

[Jon]

Closing, this isn't a uru issue.

As a temp workaround to paperclip's cross-platform issue you can place DevKit artifacts on PATH before using uru for the first time. But beware potential PATH conflicts.