As a Windows user, I feel like I’m always dealing with issues that present themselves as a result of not being on a POSIX based operating system.
Tools like Git and Node (and programming languages like Ruby and Python) of course have their own Windows versions, but I feel they are truly second class citizens. You are guaranteed to run into an issue or limitation here or there.
I’ve managed to work my way around pretty much all of these issues, but now as I enter into a realm of dumping WAMP and using virtual machines for development (meaning Trellis, which requires VirtualBox and Vagrant), there becomes a careful balancing act of how you must manage your developer tools as a Windows user.
After a lot of thought and tinkering, I’ve come to conclude the following:
1) Avoid cygwin
Although something cygwin (Babun) seems like a nice choice, I feel it’s probably more trouble than it’s worth. There is a cognitive dissonance I must carry when being in the environment it provides.
- I find that how it maps a Unix-like directory structure into your Windows directory structure to be well done but can get confusing especially when switching to a real Unix-like environment.
- You can launch Windows programs from Babun (like notepad), but if there is a program that is both a Windows and Babun-installed program, this can quickly lead to confusion. For example, Git can come from both Windows and from Babun, so this can be very troublesome as well.
2) Use Window’s cmd.exe, but ONLY for managing vagrant.
vagrant up, vagrant halt, vagrant destroy, etc. Just cd into the project directory and run vagrant only. VirtualBox and Vagrant run without too many issues on Windows.
Make sure not to run cmd.exe as Administrator. Of course, you’ll need to make sure vagrant’s hosts updater correctly updates your Windows hosts file which is a protected file.
3) Create a dedicated Linux “command box” machine (this is the key point)
Since we’re avoiding cygwin altogether and only using cmd.exe to run Vagrant, we need a reliable environment to be able to run things like Git, Ansible and other general file management utilities.
I think having a dedicated virtual “command box” virtual machine that’s (a) ALWAYS running and automatically runs on boot (b) I’m always SSH’ed into using Putty and (c) is has access to my “Projects” directory via shared folders is the way to go.
From this command box machine, I’d go do my git commits from within my specific project directory (ie: /vagrant/Projects/project-x/).
From this command box machine, I can also SSH into my other projects, each of which have their own VM’s (make sure SSH keys are setup correctly). Alternatively, I could open a new Putty window and connect from there. It’s just a matter of personal preference.
4) Each project has it’s own VM
As is best practice, each project should have it’s own VM. Pretty much all Trellis at this point.
Workflow / putting for putting it all together with a new project, like roots-example-project.com (use your paths accordingly):
Inside “Command Box” (assuming you’re already SSH’ed into it)
cd /vagrant/Projects/
git clone git@github.com:roots/roots-example-project.com.git
Inside cmd.exe
cd c:\Users\jlahijani\Projects\roots-example-project.com\
vagrant up
Inside “Command Box”
ssh vagrant@your-trellis-box-ip-address -p the-port-number
Now that you are SSH’ed into the Trellis Project box, go to the theme dir and run npm install, bower install, gulp watch, etc.
I’d like to hear any thoughts on this.
Jonathan
