Julia (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
flowerhack) wrote2014-05-19 09:44 pm
flowerhack) wrote2014-05-19 09:44 pm
Entry tags:
Why I Like Vagrant
Today, I was talking to another developer who works with me on a certain OSS project, and they mentioned that they preferred setting up their development environment by hand, rather than using the Vagrant file the project provides. This surprised me, because I've been using Vagrant in various forms since last September, and it's been such a delightful experience that I think everyone should try it. (Or, if you're involved with an open source project that still expects developers to do all their installing and provisioning by hand—consider Vagrant! They may thank you for it.)
The Problem
About halfway through my undergrad career, I noticed that VMs for particular computer science classes were becoming popular, i.e., such-and-such class would expect you to download their VM and do all your coursework on it. I hated using those VMs, because VirtualBox had a cludgy gross interface, and because my machine seemed to always crawl to a halt while using it, and I could never quite get folder-sharing or internet-ing set up quite right, and even getting copy 'n' paste set up (leading to truly sad scenarios where you'd be taking screenshots of stacktraces).
But the alternative, "just install everything by hand," is often even more unpleasant, particularly for scenarios more complicated than a coursework setup. For demonstration purposes, I dug up some notes from a couple months ago, when I was trying to get a popular open source Ruby on Rails project set up on my machine. It had step-by-step OSX install instructions and everything; this was totally going to be a breeze, right?
Hahahaha.
The Solution
Aforementioned RoR project now uses Vagrant, and it's positively magical. There's three simple steps:
It's still a VM but everything about it just plain works better. I never have to look at VirtualBox's gross UI; I can just work from the command line. Folder sharing with my host machine works out-of-the-box—so I can use my beloved Sublime Text on my host machine to edit files on the VM right away.
Not only is it easy to set up, it's easy to tear down, too. If my development environment ever gets borked, I just do "vagrant destroy", then another "vagrant up" and it's back to developing again, good as new.
Also, if I have a problem on my environment, then it's way more likely that everyone else is having that problem, too (since so many other developers are using that Vagrantfile + VM image)—so it's easier to find help.
Why not use Vagrant?
I went around and polled a couple developer friends: "in general, when you're contributing to a new project, do you prefer a VM handed to you or a series of install scripts / similar instructions?" I discovered quite a few who preferred VMs for the simple reason that "it's easier" or "I'm lazy," which is totally reasonable (cue the programmer virtues). The people who preferred scripts gave a couple reasons, most of which Vagrant neatly addresses:
VirtualBox is gross. It is. The UI is kludgy and the app is kind of disappointing. Luckily, Vagrant makes it to where you never have to actually look at VirtualBox; it runs it in the background. Unfortunately, the memory overhead of VirtualBox is still there, but for general webdev-ish type stuff, I've found it runs quick enough.
VMs are large. They are. But, nowadays, your hard drive is probably also large—as in, large enough to easily accommodate a few VMs with room to spare. One of the VMs I'm using for development right now is two gigabytes—which is big, but my hard drive is 250 gigs. I could install ten of these VMs and still have over 90% of my hard drive left over for whatever else I need on there.
This still isn't great if you're trying to develop on a netbook or something similar, but for many developers, VM size is not the issue it was five or ten years ago.
You don't know how the VM got in its present state. This is a reasonable point. While you often don't need to know how the VM got that way in order to do development on it, there are cases when you really do want to know—for instance, if you want to install it on your own server. But Vagrant isn't just a VM image—the Vagrantfile contains all the instructions for what to download and install and such—so you can read the Vagrantfile for more detail.
(Bonus: I've found that tinkering with the Vagrantfile is more accessible than just executing random commands, and it's helped me understand my development environment better. When I wanted to install and edit another repo alongside the main project, I talked with our friendly neighborhood test engineer, and they showed me where in the Vagrantfile to go to set up NFS file sharing and what to edit. I then spent a gleeful two hours poking around the Vagrantfile out of curiosity. Before, when I'd set up dev environments, it was strictly a one-and-done affair, and I didn't understand much of what was going on; now, it was easier to see how everything hooked together and tinker with different setups myself. Awesome!)
It's not all ponies, of course. Whoever goes about writing the Vagrantfile needs to be thoughtful about it, and a few weird bugs can surface from time to time due to Vagrant magic. (Once I ran into a bizarre test failure that was ultimately caused by a unicode encoding issue that could only occur by running Ubuntu on an OSX host machine with NFS file sharing. I should do a writeup on that one sometime.) But on the whole, it makes the whole business of handling VMs much simpler and cleaner and hassle-free, so you can spend more time developing and less time mucking around in dependencyland.
You can check out Vagrant here!
The Problem
About halfway through my undergrad career, I noticed that VMs for particular computer science classes were becoming popular, i.e., such-and-such class would expect you to download their VM and do all your coursework on it. I hated using those VMs, because VirtualBox had a cludgy gross interface, and because my machine seemed to always crawl to a halt while using it, and I could never quite get folder-sharing or internet-ing set up quite right, and even getting copy 'n' paste set up (leading to truly sad scenarios where you'd be taking screenshots of stacktraces).
But the alternative, "just install everything by hand," is often even more unpleasant, particularly for scenarios more complicated than a coursework setup. For demonstration purposes, I dug up some notes from a couple months ago, when I was trying to get a popular open source Ruby on Rails project set up on my machine. It had step-by-step OSX install instructions and everything; this was totally going to be a breeze, right?
Hahahaha.
- Get a "zlib not found" error while going through the install steps.
- Google that error. Dig through dozens of results to discover that, while many people have problems similar to yours, none are exactly your problem, and thus, none of their fixes work.
- Hop onto IRC to ask helpful strangers—except, oh no, freenode is getting DDOS'd. In between DDOSes, ask the folks in #bundler what might be going on.
- With the help of the #bundler folks, I determine that, though "ruby -v" says I'm running 1.9.3, and ".ruby-version" says I'm running 1.9.3, and "rbenv -versions" has 1.9.3, for some reason bundler is trying to use ruby 1.8.7.
- Maybe that one command involving bundler before shouldn't have been done using 'sudo'?
- Try and re-run the command without sudo. Now brew is complaining about SHA1 mismatches. Evidently this is because my version of XCode is like a day out of date.
- Update XCode. This is a 4 gig download and my environment's still not guaranteed to run once it's done. Sigh.
The Solution
Aforementioned RoR project now uses Vagrant, and it's positively magical. There's three simple steps:
- vagrant up
- vagrant ssh
- start_my_app
It's still a VM but everything about it just plain works better. I never have to look at VirtualBox's gross UI; I can just work from the command line. Folder sharing with my host machine works out-of-the-box—so I can use my beloved Sublime Text on my host machine to edit files on the VM right away.
Not only is it easy to set up, it's easy to tear down, too. If my development environment ever gets borked, I just do "vagrant destroy", then another "vagrant up" and it's back to developing again, good as new.
Also, if I have a problem on my environment, then it's way more likely that everyone else is having that problem, too (since so many other developers are using that Vagrantfile + VM image)—so it's easier to find help.
Why not use Vagrant?
I went around and polled a couple developer friends: "in general, when you're contributing to a new project, do you prefer a VM handed to you or a series of install scripts / similar instructions?" I discovered quite a few who preferred VMs for the simple reason that "it's easier" or "I'm lazy," which is totally reasonable (cue the programmer virtues). The people who preferred scripts gave a couple reasons, most of which Vagrant neatly addresses:
VirtualBox is gross. It is. The UI is kludgy and the app is kind of disappointing. Luckily, Vagrant makes it to where you never have to actually look at VirtualBox; it runs it in the background. Unfortunately, the memory overhead of VirtualBox is still there, but for general webdev-ish type stuff, I've found it runs quick enough.
VMs are large. They are. But, nowadays, your hard drive is probably also large—as in, large enough to easily accommodate a few VMs with room to spare. One of the VMs I'm using for development right now is two gigabytes—which is big, but my hard drive is 250 gigs. I could install ten of these VMs and still have over 90% of my hard drive left over for whatever else I need on there.
This still isn't great if you're trying to develop on a netbook or something similar, but for many developers, VM size is not the issue it was five or ten years ago.
You don't know how the VM got in its present state. This is a reasonable point. While you often don't need to know how the VM got that way in order to do development on it, there are cases when you really do want to know—for instance, if you want to install it on your own server. But Vagrant isn't just a VM image—the Vagrantfile contains all the instructions for what to download and install and such—so you can read the Vagrantfile for more detail.
(Bonus: I've found that tinkering with the Vagrantfile is more accessible than just executing random commands, and it's helped me understand my development environment better. When I wanted to install and edit another repo alongside the main project, I talked with our friendly neighborhood test engineer, and they showed me where in the Vagrantfile to go to set up NFS file sharing and what to edit. I then spent a gleeful two hours poking around the Vagrantfile out of curiosity. Before, when I'd set up dev environments, it was strictly a one-and-done affair, and I didn't understand much of what was going on; now, it was easier to see how everything hooked together and tinker with different setups myself. Awesome!)
It's not all ponies, of course. Whoever goes about writing the Vagrantfile needs to be thoughtful about it, and a few weird bugs can surface from time to time due to Vagrant magic. (Once I ran into a bizarre test failure that was ultimately caused by a unicode encoding issue that could only occur by running Ubuntu on an OSX host machine with NFS file sharing. I should do a writeup on that one sometime.) But on the whole, it makes the whole business of handling VMs much simpler and cleaner and hassle-free, so you can spend more time developing and less time mucking around in dependencyland.
You can check out Vagrant here!