I regard Vagrant as indispensable for Ruby on Rails development. (My setup is at https://github.com/jhsu802701/vagrant-debian-jessie .) Before I learned to use Vagrant, I used VirtualBox directly for Ruby on Rails development.
That said, I also know that most people rely on Ruby on Rails installed directly on the host OS. I never liked this setup, because there was no way to return Ruby on Rails to its initial state. If anything went wrong, then I either had to troubleshoot the Ruby on Rails setup or reinstall Ruby on Rails. I was unable to proceed any further on the project until I resolved this matter. Additionally, there’s also the “works on my machine” problem. There were times when I tried to transfer my Rails app to another machine or deploy it, only to be greeted by very long error messages because of setup details that I forgot. There were also times when I published a Ruby gem, only to get weird errors when I tried to use it. These problems were most likely to crop up when I used “gem install” to install a Ruby gem but forgot to add the gem to the Gemfile/gemspec or when I made changes to the Gemfile/gemspec.
As a result, I insist on using Vagrant so that I can return Ruby on Rails to its initial state. I also insist on including in each project a setup script that handles the setup AND testing. When I rebuild my Vagrant box, git clone the project, and run the setup script, all of the tests should proceed as expected. If that’s the case, then I am assured that I have covered all of my bases. If I get errors, or if strange things happen, then I know that I haven’t covered all of my bases and need to update my setup script/instructions.
That said, I’d like to hear from those of you who are still part of the vast majority who use Ruby on Rails directly on the host OS. How do you deal with the issues that prompted me to use VirtualBox/Vagrant? (I think that gemsets are a popular solution. Is this correct?)
I used to develop inside a virtual machine as well (VMWare and VirtualBox) but made the switch to development on the same operating system for hardware reasons. The “workstation” I was provided with didn’t have the specifications to run a virtual machine inside its host operating system.
Even though sometimes it’s frustrating, having to work through missing dependencies and the like is a good experience. I work on a small team where both of us are full-stack developers. When something goes wrong we can only rely on one another and have to solve problems with no other assistance.
Being able to scrap a VM instance or reset it surely is convenient but I feel that it prevents you from gaining some development (system administration, really) experience.
My $0.02.
On Wednesday, December 2, 2015 at 11:46:49 AM UTC-6, Jason Hsu, Ruby on High Speed Rails wrote:
On 2 December 2015 at 17:46, Jason Hsu, Ruby on High Speed Rails
..
That said, I'd like to hear from those of you who are still part of the vast
majority who use Ruby on Rails directly on the host OS. How do you deal
with the issues that prompted me to use VirtualBox/Vagrant? (I think that
gemsets are a popular solution. Is this correct?)
I use rvm with gemsets (on Ubuntu) and rarely have any of the problems
you describe. rvm, ruby and rails with dependencies are installed in
two commands as described on rvm.io
Each app specifies the ruby and gemset to use in .ruby-version and
.ruby-gemset so there is very little that can go wrong. Bundler
installs all the gems needed for the app to the gemset.
Starting from a virgin machine with Ubuntu installed I reckon I could
have everything needed installed and an app checked out of its git
repo and running in less than 30 mins. Much less probably.
On Wednesday, December 2, 2015 at 5:46:49 PM UTC, Jason Hsu, Ruby on High Speed Rails wrote:
That said, I'd like to hear from those of you who are still part of the vast majority who use Ruby on Rails directly on the host OS. How do you deal with the issues that prompted me to use VirtualBox/Vagrant? (I think that gemsets are a popular solution. Is this correct?)
I don't use gemsets - when using a bundler enabled project it won't let you load a gem that's not in the Gemfile. If I did need to blow away my ruby install that's only one command with rbenv (and then run bundler to reinstall gems). "Works on my machine" problems are handled by a CI server (which is an automatically built image, built using the same process that builds our production images)
There is some value in getting new developers setup (there are a few non ruby related dependencies in our app on top of rails) but I've never really had the problems you describe.
What kind of “workstation” were you provided? It sounds like your employer provided you a computer from the Windows 98 era. I’m surprised that your employer couldn’t even cough up $50-100 for a used desktop PC.
It was quite bad. A dell optiplex GX270. I remember its model number because it haunts my nightmares.
We now have some speedy workstations but for some time it was rough. We’d rarely run tests because they took so long and caused the PC to become unresponsive.
How long ago was this? According to the spec sheet (Computers, Monitors & Technology Solutions | Dell USA), the Dell Optiplex 270 came with Windows 2000 or XP and an 800 MHz Pentium processor. This sounds like a relic from about 2001 or 2002, which is eons ago when it comes to computers. Given that Ruby on Rails is much more demanding of computer resources than word processing, spreadsheets, email, or casual web browsing, I can’t imagine trying to get anything done on such a clapped-out beater.
I thought I knew why I use gemsets (I have a different one for each
combination of ruby/rails, major rails version that is, that I use, so
1.8.7@rails_2.3, 2.0.0@rails_4.2 etc) but I am not so sure now that it
is worth it. It does mean that as I obsolete a version of rails I can
remove the old gemset and so delete the old gems. How do you stop the
global gemset from ending up with hundreds of obsolete gems, or do you
just not bother about it?
I don’t really bother with it. There’s a new ruby upgrade every couple of months & so my gem collection starts afresh each time I update ruby (& I am fortunate in that I only ever really use one ruby version at a time)
There's also `gem cleanup` command which will remove all but latest
version gems. Though usually followed by `bundle install` in each
projects for reinstalling not-so-latest gems.
And for complete gem isolation, there's always `--path` parameter for
bundle install.