david-a-wheeler
commented
4 years ago Here are some options:
Create a Ruby-level virtual environment. The two main ways of doing this are rbenv and rvm. This seems like the "right approach" but seems absurdly complicated for end-users who want to just install & run the software. Indeed, its complications give me pause. For rbenv this requires you to install rbenv, install plugin ruby-build, build ruby, install plugin rbenv-gem-rehash, install plugin rbenv-gemset , use bundler to actually download the gems, and then activate it. And I say that as someone who's used rbenv for a while; what I'm worried about is how complicated it will be for others. Discussion here: https://www.develves.net/blogs/asd/2016-03-17-using-virtual-environments-ruby-1/ and https://www.develves.net/blogs/asd/2016-04-07-using-virtual-environments-ruby-2/ . Notes:
- that text recommends installing plugin
rben-build. While we want to work across arbitrary ruby versions, that seems like a reasonable precaution to ensure we are using one that works. - that text recommends installing
rbenv-gem-rehashto ensure rbenv shims are up to date with the latest gem changes, but that functionality is now in the core of rbenv (so no need to install it separately). - It also recommends installing
rbenv-gemset. The rbenv documentation itself says, "Bundler is a better way to manage application dependencies. If you have projects that are not yet using Bundler you can install the rbenv-gemset plugin." We use Bundler (with Gemfile.lock), so you'd think we'd be covered. But it's not clear we actually are.
Docker. That works, it’s heavyweight. Everything above the kernel goes in the Dockerfile, & you must install Docker to run it.
Omnibus. This creates a package “for that system”, so you have to create a large number of packages (one for Debian, one for RHEL, one for OSX, one for Windows, etc.). You also need to set up an infrastructure that builds the packages. Info here: https://github.com/chef/omnibus . Discussion here: https://scoutapm.com/blog/omnibus-tutorial-package-a-standalone-ruby-gem
“Travelling Ruby”. This creates self-contained Ruby app packages that Include a Ruby binary. On the other hand, only a relatively few number packages must be needed (x86-32 Linux, x86-64 Linux, MacOS, and maybe Windows). See: https://phusion.github.io/traveling-ruby/ “Pact” uses this: https://github.com/pact-foundation/pact-ruby-standalone Discussion here: https://github.com/jekyll/jekyll/issues/3409
Fpm - https://github.com/jordansissel/fpm - builds system-specific packages for a variety of systems.
Book “Build Awesome Command-Line Applications in Ruby 2” - https://doc.lagout.org/programmation/Ruby/Build%20Awesome%20Command-Line%20Applications%20in%20Ruby%202_%20Control%20Your%20Computer%2C%20Simplify%20Your%20Life%20%5BCopeland%202013-11-25%5D.pdf – includes in section 7.2 “”Distributing without RubyGems”. Basically, use “gem2rpm” and create an RPM file for RHEL/Fedora. But only for that one. Not really helpful.
Ruby-packer https://github.com/pmq20/ruby-packer - works on Linux, Mac, Windows. Creates a binary “distribution” of application. Appears to use squashfs on Linux (so you have to install that, but that’s okay). Seems to be related to enclose.io. See: https://nts.strzibny.name/making-a-ruby-executable-with-ruby-packer/
Enclose.io - http://enclose.io/ - compiles everything into a single executable (with a pre-compiler).
I could look at how RubyMine creates its install: https://www.jetbrains.com/help/ruby/installation-guide.html#
Create a snap package. https://snapcraft.io/ Linux only. Ubuntu initiative. You can use them on Fedora; gnome-software-plugin-snap is disabled, but you can still install snaps: https://www.omgubuntu.co.uk/2019/07/fedora-31-snap-plugin-removal
Create a Flatpak.package. https://flatpak.org/ Linux only. Red Hat initiative. See: https://flatpak.org/faq/
AppImage. See: https://appimage.org/ A guide is here: https://itsfoss.com/use-appimage-linux/ - an AppImage is a single file executable, with everything needed to run inside it.
Comparisons of some options are here:
- https://github.com/3scale/3scale_toolbox/issues/26
- https://www.fossmint.com/appimage-flatpak-and-snap-from-a-software-deployment-perspective/ - compares AppImage, Flatpak, and Snap.
I found a lot of “not helpful” material (generally too basic), e.g.:
- https://www.rubyguides.com/2018/12/ruby-argv/ has basics of CLI, doesn’t go into this.
- https://learn.co/lessons/ruby-cli-applications-readme
- https://github.com/markets/awesome-ruby - list of interesting Ruby things
- Appraisal tests against a variety of dependencies. Interesting but not my goal. https://github.com/thoughtbot/appraisal
- https://blog.lunarlogic.io/2015/how-to-write-command-line-applications-in-ruby-with-gli/ - doesn’t deal with distribution/install
mensfeld
The "easy" way to install Railroader is also fundamentally flawed. If you just run "gem install railroader" inside a larger project (such as a Rails project to be analyzed), the gems that Railroader uses must be compatible with the project being evaluated.
Tying the libraries used by the analysis tool (Railroader) and the program being evaluated (the "target of evaluation", or TOE), seems fundamentally wrong. They should NOT be tied. Separating them would make it much easier to install & use Railroader.
We should examine options for downloading/installing Railroader that do not tie them together. Ideally those options should make it easy to install Railroader for a variety of platforms.
Below are some options I've identified.