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