4 ms·

This is awesome, and I'd love to use it for the command-line dev tools that I write. Unfortunately this gem requires Ruby 2.3+, but macOS built-in Ruby, which i

by jitl 9y ago

This is awesome, and I'd love to use it for the command-line dev tools that I write. Unfortunately this gem requires Ruby 2.3+, but macOS built-in Ruby, which is the Ruby we target, is only 2.0.0. Does anyone know of a good solution for prebuilt, relocatable Rubies on macOS that I could easily bundle with my tool? I'm reluctant to use Homebrew or another package manager like rbenv, where I'd have to implement a non-trivial bootstrap process. Phusion's travelling-ruby project would be perfect, but it's unmaintained. I just want my CLI to boot in 0.05s without needing to change languages. Love Ruby, but getting decent perf takes a bit of effort.

jacobevelyn 9y ago
As a fellow Ruby CLI developer, I feel your pain exactly. I've been planning on exploring Traveling Ruby[^1] for exactly this reason (as well as the fact that telling users they need to `sudo gem install` something is non-ideal) but hadn't yet gotten around to it. Out of curiosity, what's your tool(s)? [^1]: https://github.com/JacobEvelyn/friends/issues/160 https://github.com/JacobEvelyn/friends/issues/160
- jitl 9y ago
  I write an internal developer tool at Airbnb that is conceptually similar to Vagrant. We get around the 'sudo gem' problem by distributing our tool as a git repo, then bootstrapping a vendored install of Bundler to manage our own little gem path using /usr/bin/ruby. We take care to remove most ruby-related env vars during init so we're safe from whatever crazy RBENV or RVM shenanigans are happening on the system. This setup works fine, but we don't get recent language perf improvements since we use system Ruby.
  - burke 9y ago
    Heh. I write an internal developer tool at Shopify that is (somewhat) conceptually similar to vagrant. (https://twitter.com/burkelibbey/status/858013844626649092 https://twitter.com/burkelibbey/status/858013844626649092) Like you, we distribute it as a git repo. We don't use bootsnap with it, but we have a few strategies that give us reasonable times: $ time ./bin/dev help up >/dev/null 0.07s user 0.03s system 98% cpu 0.102 total * We vendor every dependency (and try really hard to avoid them in the first place -- we have 5, only one of which is >5 source files), and prevent loading rubygems. Rubygems takes a long time to load. Our shebang is `/usr/bin/ruby --disable-gems`. * Autoload everything. Our toplevel lib/dev.rb file is a whole-namespace autoload registry. Only a few other constants are defined there. Everything is loaded just by cascading through autoloads. * Defer stdlib requires: We load most stdlib features within the method body from which they're used. Several stdlib features take a surprisingly long time to load.
    - jitl 9y ago
      Great tips! We should do the refactor work to switch to lazy-loading everything, but that will take some time. I can certainly get the Rubygems savings today though.
    - jacobevelyn 9y ago
      Thanks for the tips! I'm definitely going to use these as well.
    - jitl 9y ago
      I pulled these requires into the method bodies where they are used: - openssl - digest - resolv - rgl - net/ssh - (internal http client) - (internal package manager) Doing this saved about 40% of our CLI boot time: $ time /usr/local/bin/airlab > /dev/null /usr/local/bin/airlab > /dev/null 0.27s user 0.15s system 79% cpu 0.521 total $ git co jake--no-rubygems $ time /usr/local/bin/airlab > /dev/null /usr/local/bin/airlab > /dev/null 0.24s user 0.08s system 98% cpu 0.326 total
burke 9y ago
Sadly, the 2.3 requirement is inherent, since the RubyVM::InstructionSequence dump/load API was introduced in 2.3.0. However, you could probably still benefit from http://github.com/byroot/bootscale http://github.com/byroot/bootscale.
guu 9y ago
Have you considered trying mruby? That would allow you to ship standalone binaries. https://github.com/hone/mruby-cli https://github.com/hone/mruby-cli
- burke 9y ago
  I can't believe I hadn't though of this. Could be a really useful idea!

by jitl 9y ago

jacobevelyn 9y ago

As a fellow Ruby CLI developer, I feel your pain exactly. I've been planning on exploring Traveling Ruby[^1] for exactly this reason (as well as the fact that telling users they need to `sudo gem install` something is non-ideal) but hadn't yet gotten around to it. Out of curiosity, what's your tool(s)? [^1]: https://github.com/JacobEvelyn/friends/issues/160 https://github.com/JacobEvelyn/friends/issues/160

jitl 9y ago
I write an internal developer tool at Airbnb that is conceptually similar to Vagrant. We get around the 'sudo gem' problem by distributing our tool as a git repo, then bootstrapping a vendored install of Bundler to manage our own little gem path using /usr/bin/ruby. We take care to remove most ruby-related env vars during init so we're safe from whatever crazy RBENV or RVM shenanigans are happening on the system. This setup works fine, but we don't get recent language perf improvements since we use system Ruby.
- burke 9y ago
  Heh. I write an internal developer tool at Shopify that is (somewhat) conceptually similar to vagrant. (https://twitter.com/burkelibbey/status/858013844626649092 https://twitter.com/burkelibbey/status/858013844626649092) Like you, we distribute it as a git repo. We don't use bootsnap with it, but we have a few strategies that give us reasonable times: $ time ./bin/dev help up >/dev/null 0.07s user 0.03s system 98% cpu 0.102 total * We vendor every dependency (and try really hard to avoid them in the first place -- we have 5, only one of which is >5 source files), and prevent loading rubygems. Rubygems takes a long time to load. Our shebang is `/usr/bin/ruby --disable-gems`. * Autoload everything. Our toplevel lib/dev.rb file is a whole-namespace autoload registry. Only a few other constants are defined there. Everything is loaded just by cascading through autoloads. * Defer stdlib requires: We load most stdlib features within the method body from which they're used. Several stdlib features take a surprisingly long time to load.
  - jitl 9y ago
    Great tips! We should do the refactor work to switch to lazy-loading everything, but that will take some time. I can certainly get the Rubygems savings today though.
  - jacobevelyn 9y ago
    Thanks for the tips! I'm definitely going to use these as well.
  - jitl 9y ago
    I pulled these requires into the method bodies where they are used: - openssl - digest - resolv - rgl - net/ssh - (internal http client) - (internal package manager) Doing this saved about 40% of our CLI boot time: $ time /usr/local/bin/airlab > /dev/null /usr/local/bin/airlab > /dev/null 0.27s user 0.15s system 79% cpu 0.521 total $ git co jake--no-rubygems $ time /usr/local/bin/airlab > /dev/null /usr/local/bin/airlab > /dev/null 0.24s user 0.08s system 98% cpu 0.326 total

burke 9y ago

Sadly, the 2.3 requirement is inherent, since the RubyVM::InstructionSequence dump/load API was introduced in 2.3.0. However, you could probably still benefit from http://github.com/byroot/bootscale http://github.com/byroot/bootscale.

guu 9y ago

Have you considered trying mruby? That would allow you to ship standalone binaries. https://github.com/hone/mruby-cli https://github.com/hone/mruby-cli

burke 9y ago
I can't believe I hadn't though of this. Could be a really useful idea!