Developing WITHOUT Vagrant/VirtualBox

[Jason Hsu, Ruby on High Speed Rails]

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?)

[dana tassler]

Hi Jason,

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.

[Colin Law]

On 2 December 2015 at 17:46, Jason Hsu, Ruby on High Speed Rails
<jhsu8...@gmail.com> 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

gpg --keyserver hkp://keys.gnupg.net --recv-keys
409B6B1796C275462A1703113804BB82D39DC0E3
\curl -sSL https://get.rvm.io | bash -s stable --rails

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.

Colin

[Frederick Cheung]

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.

Fred

[Colin Law]

On 2 December 2015 at 21:46, Frederick Cheung

<frederic...@gmail.com> wrote:
> 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.

Can you explain what you mean by that in more detail please, I don't
understand what you are saying.

Colin

[Jason Hsu, Ruby on High Speed Rails]

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.

[dana tassler]

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.

--
You received this message because you are subscribed to a topic in the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rubyonrails-talk/hy7hFHszZeQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/c9d254e5-0e72-4dbc-b9bd-166bec59fa8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

"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.

[Jason Hsu, Ruby on High Speed Rails]

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.

[Frederick Cheung]

If you are using bundler, you can only load gems in the Gemfile or Gemfile.lock

You can see this easily enough with a dummy project: create a folder with an empty Gemfile, and put this in test.rb

require 'bundler/setup'

require 'uuid' # replace with the name of some gem that is installed on your machine.

Running test.rb will fail with a LoadError. Add the gem to the Gemfile (no need to run bundle) and test.rb will run successfully.

Fred

[Colin Law]

On 3 December 2015 at 10:40, Frederick Cheung

<frederic...@gmail.com> wrote:
>
>
> On Wednesday, December 2, 2015 at 10:00:48 PM UTC, Colin Law wrote:
>>
>> On 2 December 2015 at 21:46, Frederick Cheung
>> <frederic...@gmail.com> wrote:
>> > 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.
>>
>> Can you explain what you mean by that in more detail please, I don't
>> understand what you are saying.
>>
>
> If you are using bundler, you can only load gems in the Gemfile or
> Gemfile.lock

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?

Colin

[Frederick Cheung]

On Thursday, December 3, 2015 at 11:09:56 AM UTC, Colin Law 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.
>>
>
> If you are using bundler, you can only load gems in the Gemfile or
> Gemfile.lock

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.

Fred

[Colin Law]

On 3 December 2015 at 13:41, Frederick Cheung

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?

Cheers

Colin

[Frederick Cheung]

On Thursday, December 3, 2015 at 2:14:17 PM UTC, Colin Law wrote:

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)

Fred

[Colin Law]

On 3 December 2015 at 16:12, Frederick Cheung

I think you have convinced me to try without gemsets on my next app
and see how it goes.

Thanks

Colin

[nanaya]

On Fri, Dec 4, 2015, at 01:12, Frederick Cheung 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.