How can I make executables included in a Ruby gem runnable on Windows? - ruby

I have a Ruby gem with some scripts that are distributed as executables. On Linux, this means that they go on the PATH with the executable bit set when the gem is installed. But on Windows, I don't see that or anything equivalent. So, how can I make those scripts usable from the command line on Windows?
I noticed that the Gem::Installer package has a generate_windows_script command, which from the brief description appears to match what I'm trying to do. Can I use that to help here, and if so, how?

Related

Creating Ruby gems with same name executables?

I want to have a Ruby Gem that will have the same executable as another Gem.
When called with command args it will either do something, or pass the command on to the other Gem.
The first problem I have is that it isn't able to run two same named executables. I get this error:
Bundler is using a binstub that was created for a different gem. This is deprecated, in future versions you may need to bundle binstub yourgem to work around a system/bundle conflict.
How can I have Gems with the same named executables and ensure that the target one executes?
You cannot rely on Bundler or Rubygems to manage this for you. All it does it copy an executable that you specified in your gem spec to its bin/ directory.
The first problem you'll have is that the executable that runs may be dependent on the order in which the gems were installed which you can't guarantee.
Another problem that you'll have is that you cannot execute code on gem installation so you will be unable to run code that would try to automate this set up for people who install your gem.
I believe your gem should provide a non-conflicting executable. You can then supply post install instructions in your gem spec that are displayed to a user installing the gem, in the README, in a blog post, etc. you can tell the user that they need to set up an alias that points to your executable. In all shells that I'm aware of aliases will be executed before filesystem executables.
For the times when people want to bypass your alias and execute the original executable you can tell people to escape the command, e.g. \original-gem. That bypasses alias and function lookup in most shells and will allow users to have your super awesome version as the default (thru the alias) and a way to easily access the original.

Packaging Compiled Binary /w a Ruby Gem

I am creating a small daemon, written in Ruby, which relies in part on a small binary utility compiled from C code. I want to package this as a gem and include this dependency along with it.
Essentially, this daemon will need to run commands such as ip addr add ... without requiring sudo, so I created a small C program to proxy those commands which must be compiled, chowned to root, and have the setuid bit set.
I would like to have the gem compile and install this dependency along with the daemon, but I am unsure how to do so. I understand extensions can be compiled via extconf.rb, but that is specifically meant for managing Ruby extensions, right? Would it be an ugly hack to have this compile and install a binary to /usr/local/bin or similar?
Does anyone know of an existing gem which does a similar thing which I can study as an example?
Here's a gem that packages the pdftk binary.
https://github.com/charliemaffitt/pdftk-heroku

How do I easily condense a whole ruby program into one file?

I really like writing command line applications in ruby. However, when working on lots of ruby projects I end up switching between different ruby versions with something like rvm, rbenv or chruby. This means I need to install ruby command line utilities for every version of ruby I work on. I've gotten used to this, but when distributing ruby command line apps to other devs they get confused when running whateverrubyapp that worked in one directory now doesn't work in another directory because the ruby version is different, or even worse they're using gemsets.
Is there an easy way to bundle up a ruby application with all it's dependencies including gems into a single file so that I can just have people put that file in their ~/bin dir so that it behaved somewhat as though it were a compiled application?
For example, I whipped up a little rake task to take a project with no gem dependencies and put it all into one file https://github.com/mmrobins/git-rank/blob/master/Rakefile. However, I have much more complex command line apps that have gem dependencies I would want to include into a single file for easy distribution.

Using gems via Rubygems in windows - path failure

I have installed ruby 1.9.3, with RubyInstaller and DevKit. I installed the required gem I'm looking forward to use, but no matter what I do i can't get it working. I run my program and i get the following runtime erro:
C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/gnuplot-2.6.2/lib/gnuplot.r
b:59:in `gnuplot': gnuplot executable not found on path (RuntimeError)
from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/gnuplot-2.6.2/
lib/gnuplot.rb:74:in `open'
from cluster.rb:182:in `<main>'
What have i done wrong? I did try to add require rubygems, run :cmd>> ruby -rubygems ...(params)..., I installed the gem via gem install gem_name in the curent working directorie, but i can't make it find my gems.
PS: I encounter this problem on windows OS.
Solution addition: the path C:....\gnuplot.exe must be added to the PATH variable
The gnuplot gem is just a wrapper for the actual gnuplot application. This means that the application needs to be installed in order for the gem to work.
Your error mentions line 59 of /lib/gnuplot.rb which is an error raised when the gem attempts to find your system's installation of gnuplot. For Windows, it is looking in your PATH system variable.
If you do not have gnuplot installed prior to using the gem, you can download and install it from its SourceForge files page.
From Gnuplot's Rubyforge site:
"If the gnuplot executable for your system is called something other than simply 'gnuplot' then set the RB_GNUPLOT environment variable to the name of the executable. This must either be a full path to the gnuplot command or an executable filename that exists in your PATH environment variable."
I'm guessing the problem is that executables in Windows end with an .exe extension, so the program is looking for something just called 'gnuplot' and isn't finding it. You can try to set RB_GNUPLOT to the full path of the executable on your system. I've had to set environment variables in Windows before, it's possible; just google the solution for you particular OS.

Is there a way to make rubyinstaller play nice with cygwin?

I was having trouble getting jekyll to work with Ruby using cygwin on Windows 7 64-bit. I had better results using rubyinstaller + devkit. It would be really nice if I could use the rubyinstaller ruby inside of cygwin.
However, I get the following message when I try to execute rake.
$ rake page name="pages/about.md"
C:\Ruby193\bin\ruby.exe: No such file or directory -- /cygdrive/c/Ruby193/bin/rake (LoadError)
Is there any way to make rubyinstaller play nice with cygwin?
I just put a few of these in my .bash_profile:
alias gem=gem.bat
alias irb=irb.bat
alias rake=rake.bat
I never have any of the problems that Luis mentions.
The problem is cygwin converting all the scripts paths into cygwin paths (/cygdrive/...).
There is no solution for that since the invoke of the script is made from bash over rake scrip which invokes native Ruby.
There are a lot of other issues that cygwin will cause, and some are covered in RubyInstaller troubleshooting page
One alternative will be invoking rake.bat directly, skipping cygwin shebang detection.
But cygwin doesn't like batch files, which forces you to do cmd.exe /C rake.bat and that is a noisy command line.
The other alternative is install something like gem-exefy (gem install gem-exefy) and generate executables for your installed gems (rake.exe).
That way you invoke rake.exe instead of letting cygwin figure it out.
Another alternative is use MSYS Bash (included in DevKit) instead of cygwin, which plays way better than cygwin one, but you will still have issues with batch files.
As you can see, mixing non-native (cygwin) with native (RubyInstaller) have a lot of side-effects.

Resources