Upon installing their first Ruby version on the system, the user may want to set it as their default; otherwise the default will remain "system" and any `gem install` attempts will fail with a permission error.
This suggestion is skipped if the user already has chosen an explicit default, even if it's "system".
As suggested by @eregon, now we have "-l/--list" option for the short
list of versions. Behaviour of `ruby-build --definitions` is kept as
before for compatibility.
rbenv-install:
-L/--list-all full list
-l/--list short list
ruby-build:
-d/--definitions full list
-l/--list short list
When a target is not found, rbenv-install proposes pulling changes from
upstream. This involves changing the directory to the ruby-build checkout.
This patch adds a '&& cd -' to change the working directory back to where
we've been. Should work on at least Bash and Zsh.
When requested via `-h|--help`, usage text should be displayed on stdout
and the exit status should be 0.
When usage text is shown due to invalid arguments, it should be
printed to stderr and exit status should be 1.
Because ruby-build is both a Homebrew formula and an rbenv plugin, some
people end up with both installed. In these cases, executing
`rbenv install` vs. `ruby-build` might not use the same install. Users
end up being unsure where `rbenv install` is coming from and upgrading
it from the wrong location.
This detect whether ruby-build is contained in Homebrew or git and shows
upgrade instructions accordingly. Example:
See all available versions with \`rbenv install --list'.
If the version you need is missing, try upgrading ruby-build:
brew update && brew upgrade ruby-build
The build definitions auto-discovered from rbenv plugins would
previously not appear in `--list` results due to discovery process
taking place too late.
The `-f` option allows for forcing installation of versions that already
exist in the environment. If that option isn't used, then an interactive
prompt is created which causes problems for non-interactive execution of
the command.
This change adds the `-s/--skip-existing` option to not install versions
that already exist, while still exiting as success.
Closes#543
Benefits:
- makes it easier to stub `rbenv-*` subcommands in tests
- speeds up subcommands because it skips the main `rbenv` executable
Caveats:
- users are no longer able to call `bin/rbenv-install` or
`rbenv-uninstall` directly
If `-p|--patch` flag was set while invoking `ruby-build` or
`rbenv install`, ruby-build will use `patch -p0 -i -` to apply a patch
from stdin to Ruby, Rubinius, or JRuby source code before running the
rest of `build_package_*` commands.
References #443
Rationale:
Both in development and in production, some usage patterns of ruby-build
are slowed down by the download phase. In scenarios such as
troubleshooting failing builds or with provisioning situations (chef,
vagrant...) the repeated download is unnerving, bandwidth wasting and
simply against etiquette towards tarball hosters.
It also happens that some source sites happen to be down and in such
cases it is helpful to be able to sideload sources to rbenv.
Behavior:
By default nothing changes.
If the variable CACHE_PATH is set, then ruby-build will use that
directory to store a successful download, and will check before
downloading if the tarball is already there, in which case downloading
is skipped.
The file is first downloaded as before in the tmp subdirectory and only
moved afterwards, thus ensuring consistency.
There is no default cache path and the optional variable is to be set by
hand, ensuring people know what they're doing when using ruby-build.
Additionnally, rbenv-install will helpfully set CACHE_PATH if and only
if a RBENV_ROOT/cache directory exists. Again, the directory has to be
created manually.
The CACHE_PATH variable internally ends with a slash to mutualize
non-cached cases. Still, consistency is ensured whether or not a slash
is provided externally.
Notes:
I'm not quite sure CACHE_PATH is a good name, maybe
RUBY_BUILD_CACHE_PATH is better and less conflicting.
