When running `rbenv init`, typically during rbenv setup, users expected
their shell environment to be modified permanently. Instead, what the
command would do is print the instructions to the user and expect them
to edit their shell initialization files accordingly. This proved to
be unintuitive.
Now, running `rbenv init <shells>...` will modify the shell initialization
files of the following shells:
- bash: `~/.bash_profile` or `~/.bashrc` if the latter exists but the former does not
- zsh: `~/.zprofile` or `~/.zshrc` if the latter exists and mentions "rbenv"
- fish: `~/.config/fish/config.fish`
If no shells were specified on the command line, rbenv will try to detect
the current shell.
It should be safe to run `rbenv init` multiple times, as the command will
avoid modifying any shell startup file that already mentions "rbenv init".
The new `_rbenv` script will be autoloaded by zsh as long as it's found in $FPATH.
It should be the package manager's responsibility to symlink or move this file
into an appropriate location.
Co-authored-by: Mislav Marohnić <git@mislav.net>
rbenv is now the most popular Ruby version manager, so we don't need to
sell it so hard. Instead, help the reader find installation and usage
instructions more easily.
The installation instructions are now simpler and pointing out that
ruby-build needs a separate install is now done in the "Installing Ruby
versions" section.
Finally, link to a wiki doc about potential downsides of rbenv along
with the comparison of different version manager tools.
It wasn't clear how to update the list of installable Ruby versions after installing rbenv from Git. This is a bit confusing for people who use rbenv to run third party Ruby apps rather than write their own and are less likely to know/care about the distinction between `rbenv` and `ruby-build`. I hadn't touched it for about 2 years and totally forgot that I'd need to manually update ruby-build.
Alternatively, it might be better to make ruby-build a git submodule.
* Move Homebrew to the top, common case for new devs
* Note that `brew install rbenv` includes ruby-build by default
* Be clear that `rbenv init` instructions are needed for shell setup
* Be explicit about starting a new shell to pick up PATH/init changes
* Use rbenv-doctor to conclusively demonstrate correct setup
* Separate upgrade instructions for Homebrew vs Git installs
Related: https://github.com/rbenv/ruby-build/pull/1106
I work on a team that has followed the Homebrew installations. More than once we've missed the `rbenv init` instruction and it has caused headaches down the road. This formatting makes it harder to miss.
The README details `eval`ing `rbenv init -`, but for some shells (such as fish) there's a difference in what should be run. It turns out that `rbenv init` on its own will print correct instructions, so we should point users to running that command instead.
It seems rbenv now comes with ruby-build. I have not investigated fully, but the previously shown command: `brew install rbenv ruby-build` caused issues on my machine. After uninstalling both and simply running `brew install rbenv` everything worked fine.
This compiles the `realpath` dynamic extension for bash which speeds up
symlink resolution. If the extension doesn't compile due to
cross-platform issues, rbenv will still work normally, although not as fast.
