5 ms·

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 t

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

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