spinel-coop/rv

If the flag --offline is passed, rv should try to operate without making network requests. For example, it should not check for available ruby versions, try to install ruby versions, or try to look up or install gems. If it's possible to run without network requests (perhaps a ruby version that meets the requested version is already installed?) it should run with whatever is already present. If it's not possible to run without making network requests, rv should fail with an error explaining the problem and a suggestion to try again without --offline because that might work.

Today, we have re-routed all four forms of help to only show the short help, the default clap provides on -h. Instead, let's provide both long and short help, like this: Global -h on any command, like rv ruby pin -h: show short help Global --help on any command, like rv ruby pin --help: show short help rv help [NAME], like rv help ruby pin: show long help rv NAME help, like rv ruby help pin or rv ruby pin help: removed, it's confusing to have many help commands

A side-effect of compiling OpenSSL statically, in advance, on a different machine is that we don't get "free" access to the SSL certificates that are stored in the macOS keychain as trusted. This creates problems if you are using tools like caddy or puma-dev that create a Certificate Authority and then install it into the OS as trusted. Browsers will trust those certs, but rv's Ruby (and commands run inside rv, like bundle install) will not trust those certs. I've personally run into this issue while testing local gem servers — bundle install from an rv ruby will fail certificate validation, even though curl and my web browser have no trouble verifying the certs using the OS certificate list. We can work around this by asking the OS for those certs and using them instead of the certs that ship inside the built Ruby: #!/bin/bash security export -t certs -f pemseq -k /Library/Keychains/System.keychain > cert.pem security export -t certs -f pemseq -k /System/Library/Keychains/SystemRoot

We have several significant opportunities to improve the ways rv caches things to make the things we do often really fast: set up the cacache crate for the other parts of rv to use unpack ruby and gem tarballs into our cacache, so we only store each file once even if it is in multiple versions of a gem install gems by copy-on-write hardlinking the files in that gem from cacache into the install directory, instead of unpacking tarballs after compiling native extensions, copy the results into cacache. on future installs simply hardlink those files as well, so any particular machine will never compile a gem more than once put git gem clones into the global cache, so you never have to do a full checkout of a git repo (eg rails) a second time

It is incredibly awesome and cool that we have both rv tool install and rv tool run working. Their respective final forms have a few extra features that make them less basically-the-same: rvx is a valid way to invoke the rv binary, and when it is invoked via a symlink named rvx, it instead executes rv tool run the install script and homebrew formula should create an rvx symlink pointing to the main rv binary to enable this rv tool run will install a tool into a completely ephemeral GEM_HOME, and not leave an installed tool directory behind after it exits. This is really only feasible after we have some other features around caching and installing finished to make this fast enough. rv tool install will not just install the tool itself, it will also create a binstub in ~/.local/bin/NAME that contains a script to run the tool with the right ruby version and only the specific tool gems available. rv tool install will check to see if ~/.local/bin is included in $PATH, and wil