Re:Rbenv 1.0.0
by dham on Friday December 25, 2015 @05:07PM
(#10792501)
I'm not sure you understand. You can have as many versions of a gem on your system as you want. You just can't have multiple Ruby versions of those gems easily without something like rbenv.
[ Parent
| on HN ]
Yeah, but that's a serious problem. I can't think of other languages that suffer from this, except perhaps Python.
Why should I have to install a single library in multiple places in my system, if I have multiple versions of Ruby installed? It's a disaster for upgrades and deployment.
Plus, tools like RVM and rbenv seem to depend on a bunch of hacky symlinking and $PATH manipulation to make things work. Ensuring that developers' laptops have the same environment as production boxes is not trivial, no matter what the authors of these tools claim.
Re:Rbenv 1.0.0
by regularfry on Saturday December 26, 2015 @03:01AM
(#10793629)
What I find annoying is that the core problem they solve boils down to manipulating three environment variables. Where's your ruby? That goes in $PATH. Where am I installing gems to? That goes in $GEM_HOME. Where am I loading gems from? $GEM_PATH. Everything else these tools try to do is icing.
Every time I have issues with rvm (which seems often) or rbenv (occasionally, I use it less), I'm reminded that Modules (http://modules.sourceforge.net/) takes care of this path fiddling and more. Yeah, it's old and it's in TCL and it doesn't solve the "how do I build a new ruby and gemset" problem but it's been working for years on the "how do I switch path" problem. I use module when I build .deb of Ruby and gems.