rbenv mysql_为什么不应该使用 rvm/rbenv，以及替代方案

最近关于 rvm/rbenv 的问题多了起来，所以我想分享我的观点，不要用 rvm 和 rbenv。

rvm/rbenv 有什么问题？

rvm/rbenv 都是多版本 Ruby 管理工具，但是工作原理不同：

rvm：在执行 rvm use 命令时修改 PATH，将所需版本的路径加入到 PATH 当中。

rbenv：开发者自行将 rbenv 的固定 bin 目录加入 PATH。rbenv bin 目录存放一些包装脚本(Shims)，在执行的时候查找对应版本的可执行文件。

这两个工具本质都是 PATH 上做手脚，一个在执行前，一个在执行中。那么问题来了，使用这两个工具意味着使用者要清楚了解自己目前的 PATH 是怎么设置的，不然就会各种提示找不到路径。而且更麻烦的是：

bash shell 分为 login/non-login，interactive/non-interactive 几种可以组合的状态，不同状态读取的配置文件优先级不同。我相信很多人都搞不清楚完整的优先级顺序。

cron 的执行环境和 bash 不同，PATH 要单独设定。

一些部署工具允许单独指定自己的 Ruby PATH，例如 capistrano，passenger。

这么多可配置的地方叠加起来，很容易让人搞不清楚当前执行的 Ruby 是什么版本——用 ssh 登录上去执行的 Ruby，可能跟你用 cap deploy 执行的 Ruby 不一样，又跟 app server 使用的不一样。

那么解决方案是？

对于新手，如果你不需要维护特定版本的 Ruby 项目，那么只需要装一个比较新的 Ruby 版本就行了，不需要管理多版本。这在不同系统下有不同选择。

Linux

使用系统源里的版本，例如 Ubuntu 18.04 源里自带了 2.5 版本：

apt-get install ruby ruby-dev

我在生产环境也只安装源里的 ruby，一个服务器只有一个唯一的 Ruby 路径，杜绝不同环境的 PATH 不一致，并且可以利用源的安全更新。

MacOS

先安装 Homebrew https://brew.sh/ ，再用 brew 安装：

brew install ruby

Windows

我没有 Windows 上开发的经验，知道有一个 RubyInstaller https://rubyinstaller.org/

如果需要管理多版本

Docker 不只是把 Ruby，还把其它所有依赖都固化下来，例如 MySQL，Redis 等等。

我在开发环境也用了很久 Docker，因为它可以把项目依赖封装起来，不污染本地环境。至于要不要在生产环境用 Docker，我觉得目前对于小项目还比较折腾(https://chloerei.com/2018/07/08/container-may-be-the-future-but-not-the-present/)，希望有一天可以用上。

总结

用一个工具前要想想为什么，需不需要，工具带来的好处是否超过带来的坏处。Keep it simple。