Always heard this advice but didn’t know why. So I looked into it. Basically, the system Ruby is fine for running sysadmin scripts (as long as you don’t add gems or try to update it). But don’t use it for development because:
the default location for gems is the system Ruby directory /Library/Ruby/Gems/2.6.0 so you will need to be superuser to install gems (and you really shouldn’t alter this folder)
you could use sudo to install gems but that’s a security risk (gem installation can run malicious code)
using Bundler is a best practice to manage gem versions and dependencies
it’s best to start projects with the newest version of Ruby and the system Ruby is 2.6.3
the pre-installed Ruby is deprecated by Apple and may disappear in future macOS releases
the default location for gems is the system Ruby directory /Library/Ruby/Gems/2.6.0 so you will need to be superuser to install gems (and you really shouldn’t alter this folder)
Why not install gems into a user managed folder? Blithely installing non-system things into a system (which could be package-managed) folder seems like a really bad idea.
Part of the argument can be easily circumvented. Have a look at gem install --user and bundle config set --global path. These allow you to install and manage all your gems in your homedir without the need for sudo. I do this all the time in Linux and OpenBSD to use the system ruby.
I see no benefit in using a separate package manager just for ruby when my package manager can do the same without me having to think about installing updates in yet another package manager. I don’t need 3.0 when developing my Rails projects. 2.7 and 2.6 are fine, the server will be running these as well probably.
Personally I like to run the same ruby as production, down to the patchlevel. I see no reason not to spend the extra 10 minutes to be sure that part of my environment isn’t hiding a surprise.
no reason not to spend the extra 10 minutes to be sure that part of my environment isn’t hiding a surprise
Mere hours of debugging subtle differences in behaviour between interpreter versions in production cash save you entire minutes of setting up the same version in dev! ;)
Didn’t we just get told not to use langs installed by homebrew because other casks use it as a dep and it will be upgraded without notice?
Yes. So:
This author didn’t get the memo on Homebrew yet. That’s okay.
Link in case anyone missed that story: Homebrew Python Is Not For You
Just wanted to say thanks for the link. I’ve updated the advice about installing Ruby with Homebrew.
Always heard this advice but didn’t know why. So I looked into it. Basically, the system Ruby is fine for running sysadmin scripts (as long as you don’t add gems or try to update it). But don’t use it for development because:
the default location for gems is the system Ruby directory
/Library/Ruby/Gems/2.6.0so you will need to be superuser to install gems (and you really shouldn’t alter this folder)you could use sudo to install gems but that’s a security risk (gem installation can run malicious code)
using Bundler is a best practice to manage gem versions and dependencies
it’s best to start projects with the newest version of Ruby and the system Ruby is 2.6.3
the pre-installed Ruby is deprecated by Apple and may disappear in future macOS releases
Did I miss anything?
Why not install gems into a user managed folder? Blithely installing non-system things into a system (which could be package-managed) folder seems like a really bad idea.
I feel like we are going back in time where the best option was just compiling things yourself and installing them in some place in $HOME.
Part of the argument can be easily circumvented. Have a look at
gem install --userandbundle config set --global path. These allow you to install and manage all your gems in your homedir without the need for sudo. I do this all the time in Linux and OpenBSD to use the system ruby.Can I ask, why it it you don’t want to use a Ruby version manager?
I see no benefit in using a separate package manager just for ruby when my package manager can do the same without me having to think about installing updates in yet another package manager. I don’t need 3.0 when developing my Rails projects. 2.7 and 2.6 are fine, the server will be running these as well probably.
Personally I like to run the same ruby as production, down to the patchlevel. I see no reason not to spend the extra 10 minutes to be sure that part of my environment isn’t hiding a surprise.
Mere hours of debugging subtle differences in behaviour between interpreter versions in production cash save you entire minutes of setting up the same version in dev! ;)