rubygems creates ruby wrappers around non-ruby executables, causing them to fail

[olbrich]

when providing executables with a gem, they get wrapped in a ruby wrapper that provides some support for using previous
versions of a gem. If the executable is not a ruby file (e.g., a bash script, php, etc..) then the wrapper will fail.

Suggestions:

• allow the gemspec to force the gem to be installed with '--no-wrapper' and leave it to the developer to properly
  wrap executables.
• check the shebang line of the executable and skip wrapping for anything that explicitly uses something other than
  ruby
• provide a warning at the time the gem is built that files will be wrapped (check for .bat files, or shebangs that don't include ruby... perhaps not perfect, but it will probably catch most cases).
• document the existing behavior better and provide instructions for work arounds for non-ruby binaries.

[olbrich]

Original rubyforge ticket

[zenspider]

As stated in the previous ticket:

I don't know of a good way to do this that works across platforms and makes sense.

Rubygems is for ruby. If a file is in your gem's bindir and listed as a gem executable, it should be ruby. If your gem has "special needs" then it should do it out of band, like create a Rakefile that does your special steps for you and list the Rakefile as an extension in the spec. Or just use a post-install message telling people to install with --no-wrapper.

Lemme know if I didn't understand something.

[zenspider]

I haven't heard back in months and I still think this is a bad idea. Closing.

[steveklabnik]

One use case:

Shoes 4 is written in JRuby. We need to pass options on startup to the JVM on the OSX platform only. Normally we'd do this via a bash script, but we can't, and since it's Ruby, the best we could do is spin up another Ruby, which would make the terrible JVM startup time absolutely unbearable.

[kigster]

@steveklabnik @zenspider @olbrich @hugogiraudel I just bumped into another valid reason in favor of allowing gem developers to install non-ruby executables automatically.

I am unaware of any way that a child process can affect the parent's process environment on UNIX, in particular, user's current directory. This is no different from Ruby scripts. However, were it a shell script, you can simply eval a string containing commands, and affect the parent shell process, including changing your current directory.

I am building a ruby version of the wd (warp directory) tool that's been available for zsh for quite some time now. I love the concept, and want to expand on it, but the core functionality of this tool is to be able to change the directory of the user that runs wd in the first place. It's easy to do in a shell, but impossible to do in Ruby.

I am currently shipping two executables with the gem: warp-dir – is a ruby file that runs the gem's code. To work around the limitation of not being able to change the directory of the parent process, I am having the ruby code generate shell compatible executable code (even for printing help). Talk about mete-meta programming :) So warp-dir ruby script is not meant to be run directly by humans. You are supposed to do something like this: eval $(warp-dir --help). So the wd executable is a tiny script that provides this functionality. And it would be lovely to have it be installed without ruby wrappers automatically. Gem user should really not worry about this type of thing.

I am glad that it looks like I can choose --no-wrapper flag while installing the gem, but it would be much more preferable if the gem author could explicitly tell rubygems not to create wrappers regardless.

One possible way to do this in a backwards compatible way, is by introducing a new config option for such scripts:

  gem.files         = `git ls-files`.split($\).reject{ |f| f =~ /^doc\// }
  gem.executables   << 'warp-dir'
  gem.non_ruby_executables   << 'wd'
  gem.test_files    = gem.files.grep(%r{^(test|spec|features)/})

By using non_ruby_executables we could add a new feature without breaking any prior expectations.

My 2c.

[mheffner]

If this is the case, it would be great to verify this at packaging time and reject the executable. It was somewhat unexpected surprise that it blew up later after installation.