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 H., Ruby on
On 2 December 2015 at 17:46, Jason H., Ruby on High Speed Rails [email protected] 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 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 H., 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.
On Wednesday, December 2, 2015 at 5:46:49 PM UTC, Jason H., 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.
Can you explain what you mean by that in more detail please, I don’t
understand what you are saying.
How long ago was this? According to the spec sheet
(http://www.dell.com/downloads/us/products/optix/gx270_spec.pdf), 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.
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.
On Wed, Dec 2, 2015 at 4:23 PM, Jason H., Ruby on High Speed Rails < [email protected]> wrote:
for hardware reasons. The “workstation” I was provided with didn’t have the
administration, really) experience.
To view this discussion on the web visit
“One way is to make it so simple that there are obviously no
deficiencies
and the other way is to make it so complicated that there are no obvious
deficiencies.”
C.A.R. Hoare, in talking about designing software.
I don’t understand why that is a problem, or do you mean that given
the above then there is no advantage to using gemsets?
It’s not a problem - it’s a feature which ensures that all the used gems are
in the Gemfile. I’ve not used gemsets since I’ve been using bundler.
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?
On Thursday, December 3, 2015 at 11:09:56 AM UTC, Colin L. wrote:
I don’t use gemsets - when using a bundler enabled project it won’t
I don’t understand why that is a problem, or do you mean that given
the above then there is no advantage to using gemsets?
It’s not a problem - it’s a feature which ensures that all the used gems
are in the Gemfile. I’ve not used gemsets since I’ve been using bundler.
On Thursday, December 3, 2015 at 2:14:17 PM UTC, Colin L. wrote:
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)
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)
I think you have convinced me to try without gemsets on my next app
and see how it goes.
On Fri, Dec 4, 2015, at 01:12, Frederick C. wrote:
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)
Fred
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.