21–30 of 115 posts
Looks interesting. It's always been pretty amazing to me that a system like RVM remains so popular when it depends on overriding the operation of basic commands like 'cd'.
Earlier quoted context omitted.
I don't see a pressing need to use RVM in production; when I deploy, I pick a Ruby version and stick with it unless there's a security issue, at which point I pull the updated REE package from Phusion/let Heroku figure it out. Considering the many times I've seen RVM installs fail due to checked-in broken code, I'd hardly call it "production ready" either.
I have to use rvm in production because debian/ubuntu install ruby 1.8 and I need 1.9.2 for rails 3. Ruby isn't in the alternatives system (yet - coming soon) so I don't see a better way.
Earlier quoted context omitted.
I don't see a pressing need to use RVM in production; when I deploy, I pick a Ruby version and stick with it unless there's a security issue, at which point I pull the updated REE package from Phusion/let Heroku figure it out. Considering the many times I've seen RVM installs fail due to checked-in broken code, I'd hardly call it "production ready" either.
> I don't see a pressing need to use RVM in production 1. Gemset isolation comes in handy. 2. Sometimes you want to have multiple ruby versions (e.g. MRI for app and JRuby for memory heavy script)
Is it production ready? RVM is.
Every week I run into problems/confusion with the environment it creates and expects.
I would never put it anywhere near production.
Pretty nice, but I actually do really like having gemsets. It gets me as close to the production environment as possible, plus it makes it really easy to clean up unused gems when I'm done with a project.
:~ which bi
bi: aliased to bundle install --path vendor/bundle
Earlier quoted context omitted.
Why not?
Because going back to non-packaged non-vetted flavor-of-the-month code is a retrograde step back to 1993. You lose consistency, you lose the ability to reliably recreate a same environment, you lose tested and low-friction security updates, you lose dependency management, you lose the security of a crypto web-of-trust, and you lose the google-fu of being on the exact same versions of software as thousands of other pe…
Edit: Just in case I'm coming off as snarky here, I don't mean to. My projects tend to be on the simpler end, and rvm saves me a lot of time. I'm sure it's a little cowboyish for bigger projects - I was just wondering if there was something about rvm that made it universally inappropriate for production use.
Double Edit: "a bunch" is probably an overstatement. rvm was a great help transitioning to 1.9.2. I'm not sure if it will provide much utility going forward.
Earlier quoted context omitted.
I have to use rvm in production because debian/ubuntu install ruby 1.8 and I need 1.9.2 for rails 3. Ruby isn't in the alternatives system (yet - coming soon) so I don't see a better way.
apt-get install ruby1.9. It's in there.
Looks interesting. It's always been pretty amazing to me that a system like RVM remains so popular when it depends on overriding the operation of basic commands like 'cd'.