I build from source. `babushka benhoskings:ruby19.src` :)
—Ben
On 28/07/2011, at 11:43 AM, Mike Bailey wrote:
> It occurred to me that RVM *could* result in ops guys feeling like the
> waiter in LA Story.
>
> http://youtu.be/z-CrML0BzOA
>
> "I'll have a half double decaffeinated half caf with a twist of lemon"
>
> While RVM is great for developer workstations, to me it doesn't seem right
> for production environments. A slightly longer explanation of my reasoning
> is here: http://mike.bailey.net.au/2011/07/rvm-in-production/
>
> What are your experiences?
>
> *- Mike*
> *
> *
>
> e. mi...@bailey.net.au
>
> w. mike.bailey.net.au
>
> --
> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-...@googlegroups.com.
> To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
>
But I certainly wouldn't want that complexity in a production environment - and have never seen it pushed as an ideal production tool. Mike: is anyone recommending RVM for production?
--
Pat
On 28/07/2011, at 11:43 AM, Mike Bailey wrote:
I humbly disagreed at
http://stackoverflow.com/questions/5864001/is-rvm-production-ready/6286677#6286677
Still, it's more production-ready than bumblebee!
Andrew
We had RVM on our Ubuntu images for a while, and having “. /usr/local/rvm/scripts/rvm && rvm use ruby-1.9.2 && …” before every command was a pain, as was managing .rvmrc files “what do you mean the deploy hung? Oh, it’s waiting for somebody to type Y to trust the rvmrc”. RVM breaks, and it's expected that you, as a developer, can easily recover from that breakage. This isn't true if it's part of an automated process for building production/test/uat/staging images.
My recommendation: build images/machines for each version of ruby you need. If this becomes a problem, it’s a sign that you’re using too many different versions of ruby, not that you should be using RVM outside of your local dev environment.
--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
But I certainly wouldn't want that complexity in a production environment - and have never seen it pushed as an ideal production tool. Mike: is anyone recommending RVM for production?
One of the most common claims is that rvm is only for use in development. In fact, rvm was originally built for a server setting and is perfect for such use. Not only does it include tools that can be easily automated to make setting up rubies / gems efficient, it also means you can have consistent environments both in development and production.
--
Pat
I know more developers who write Ruby based on the install they have
locally on their machines than developers who know the difference. Are
you running apps on your server that rely on language features that
match the ones you have on your development machines? If yes, then you
just don't need it. Granted, it's unlikely you'll run a bunch of Ruby
apps, each using a different version of Ruby, on the same server. But
the answer to your question depends on whether that's the case or not.
I use RVM on a VM I run my website and a couple of other things. It's
all Ruby 1.9. I don't really need it. It has never gotten in the way
anyway. Just rather have my rubies and gems sandboxes away from each
other.
P.S.: it's probably not flawless, but reasons not to use RVM in
production more often than not come down to "I feel it's wrong". The
rest seems to circle around not knowing the tool too well.
Andrew
Hah, okay... well, anyone beside the author of RVM, then?
P.S.: it's probably not flawless, but reasons not to use RVM in
production more often than not come down to "I feel it's wrong". The
rest seems to circle around not knowing the tool too well.
Yeah, I read it.
http://serverfault.com/questions/227510/is-it-possible-to-skip-rvmrc-confirmation
--
Pat
@ Pat: me neither. That usually fixes a lot of problems all around.
@ Michael: agreed, that's what Bundler is for. Again, should you
always run your apps on the same version of Ruby, it is a waste of
time.
But I certainly wouldn't want that complexity in a production environment - and have never seen it pushed as an ideal production tool. Mike: is anyone recommending RVM for production?
But it was a pain. When this ends up breaking I'll probably just
switch to a simple binary install (or source if necessary).
For the case that you have a few small, for-fun apps running on the
same server, it's probably as easy to upgrade them to work with one
recent ruby as it is to get multiple rubies working.
And I use bundler instead of gemsets.
Cheers,
Chris
On Thursday, July 28, 2011, Dmytrii Nagirniak <dna...@gmail.com> wrote:
>
> On 28 July 2011 12:25, Julio Cesar Ody <juli...@gmail.com> wrote:
>
>
> @ Michael: agreed, that's what Bundler is for. Again, should you
> always run your apps on the same version of Ruby, it is a waste of
> time.
>
> That's not why RVM exists. If everything you run is on one ruby version then there's no point of using RVM at all.In this case RVM is a tool that solves no problem.
As for .rvmrc, I haven't yet heard a good reason why checking it in is
bad, and I can think of a few reasons it's convenient. I can be
convinced though; and I haven't done a lot of searching to find
opinions conflicting with mine :)
Simon.
I don't think it's a matter of "I feel it's wrong". It's that I don't want my production ruby runtime to rely on a large set of bash scripts that are prohibitively hard to properly understand or debug quickly.
As soon as you include RVM, you have a bunch of environment-related complexity that wasn't there before, and unless you're using multiple rubies on one server, it's complexity for no gain.
—Ben
All deployment is with Capistrano, and gemset switching with .rvmrc containing something like this:
rvm use 1.9.2@app_name --create
Takes care of any issues.
I think if we weren't using Chef we probably wouldn't need RVM as we don't run any apps on 1.8.7. But honestly RVM is not a problem once you know what it's doing behind the scenes and have it setup correctly.
I hear what Ben is saying about it being unnecessary complexity, and in most cases it is, but there is times when you need it. In the near future I plan to reconfigure our master image with something like Babushka and/or Dollhouse and remove RVM and Chef completely.
But for now it works, and has done for months.
– Ivan
Are there other common uses?
—Ben
I've never found a use for .rvmrc (or gemsets), given that I pretty much bundle everything.
—Ben
On 28/07/2011, at 1:33 PM, Simon Russell wrote:
Ahh, reading Ivan's message, it's obvious now - to automatically select a ruby per project.
Are there other common uses?
I mean, if you have path issues on the production box, or something else breaking the ruby runtime, it's an order of magnitude easier to debug if RVM isn't involved, because there's no shell fiddling going on.