
Ask HN: Best practices for OS X dev environments - sassypants
I&#x27;m about to get a new Mac and will be starting fresh on a new drive. I would like to know if there are any best practices in regards to creating multiple user accounts, with different permissions for my scattered development work.<p>I spend time with node, python, and RoR. I like cloning projects from github and taking them for a spin. I test out bitcoin projects, and send GPG emails, and ssh into multiple servers. And I do all of this on my main user account that has sudo.<p>Is there some best practice that I should be aware of that would have me use multiple unix users on my new Mac?
======
geerlingguy
I've been using Ansible + Homebrew + Vagrant/VirtualBox for the past couple
years, and am now able to provision a new Mac for myself in about an hour
(with all my apps and settings in place for development) with a good internet
connection.

See: [https://github.com/geerlingguy/mac-dev-
playbook](https://github.com/geerlingguy/mac-dev-playbook)

Once you start using VMs and/or containers for your development, you'll stop
worrying about environments and breaking things :)

------
JimDabell
Don't install server-side stuff directly on your Mac. If you are working on
server-side projects, then use virtual machines. Vagrant in combination with a
configuration management system (e.g. Puppet) is very helpful here.

Use Homebrew to install command-line tools. Use Homebrew Cask to install GUI
tools that aren't on the Mac App Store.

Lots of people find it useful to check their environment's configuration files
into version control – check out popular dotfiles repositories. On OS X, this
also includes scripts that call `defaults write` for integration with OS X
preferences.

As far as multiple unix users are concerned, just create them and use them.
There's no special trick you need.

~~~
keslag
Vagrant has been a much bigger time sink for me than benefit. The ssh-agent
never works while provisioning for nix servers, only during ssh (which I can
do using the -- -A regardless). It often gets confused and the machines need
to be destroyed and re-created after 1-2 provisioning attempts. Packers (The
tool used to create vagrant boxes) lack of support for winrm on windows
systems has also been a bone of contention. It requires a number of
workarounds (like installing open-ssh) on the windows VM that in no way would
be viable on a production windows server. And that divergence allows for the
"It works on my machine" bugs which is really the whole point of using
Vagrant. I use chef for provisioning, and Vagrant also downloads the chef
provisioner every single provision, I suspect it does this with puppet as
well, so if you're developing on the go and need to re-provision, you're
either out of luck or require an unlimited data plan.

Homebrew Cask also has no oversight for breaking changes, so use this only as
a convenience, not a tool to be relied upon. It frequently looses track of
applications, and I can't even find where it decides to put some error logs if
they're created at all.

Some of these problems could be my lack of experience in operations, but the
documentation for these is far from complete. A VM with snapshots and a good
backup strategy will serve you better in the short term. This changes if
you're attempting to support multiple dev, but if you're a lone guy, then
snapshots are far far less buggy.

~~~
Quequau
> Vagrant has been a much bigger time sink for me than benefit.

This has been my experience as well... and I would really, really like to have
a system in place where I could painlessly spin up VMs to do development in,
so that I could leave my Mac as is.

~~~
mateuszf
It's called Docker.

~~~
keslag
Docker just spins up a VM on OS X with boot2docker so you don't get any real
benefit here.

~~~
ithkuil
Yep, although it creates only one you can run a bunch of containers in it.

It feels almost as a native support, but the hack is betrayed by the
networking setup.

I wish it would be possible to just expose ports on the real localhost.

~~~
keslag
Absolutely, I should have specified 'a single vm' in my response. I didn't
understand that when I was first trying to understand boot2docker, and now I'm
using imprecise language to help confuse others. Thanks for clarifying.

------
ytjohn
I use vagrant + virtualbox myself and spin up development environments on the
fly. It really is "the way to go". Work actually provides vmware fusion (and a
license for vagrant), which also works pretty well. Fusion offers more
networking options (like if you're working on pxe boot images), but I found
that it's easier to track and support virtualbox images.

One thing that I've thought about trying though, is Boxen. Github supports
hundreds of developer macs and they built this framework to do so. It looks
pretty incredible. [https://github.com/blog/1345-introducing-
boxen](https://github.com/blog/1345-introducing-boxen)

------
focusaurus
I don't think you will find multiple OSX user accounts viable/enjoyable. OSX
puts a lot of important preferences (keyboard/mouse settings for example)
within the user account, so you will end up having a nightmare keeping things
in sync and sane. You won't be able to rely on a lot of important tools like
dropbox or 1password easily. Just stick with 1 user. Use docker or
virtualbox/vagrant for stuff you don't want to run as your OSX user.

Here are some of my tools and tips.

\- homebrew is great \- homebrew cask is helpful, too \- 1password or similar
\- virtualbox can give you clean playgrounds and test environments that match
your servers \- boot2docker is handy for quickly starting and running services
like databases without polluting your mac directly too much \- I also get a
lot of use out of vagrant but YMMV \- I've lately started using project-
specific instances of chrome (created with the chrome SSB script). This lets
me keep lots of tabs separate and easily pause work and resume later \- The
chrome Tabs Outliner plugin is also really key

Here's my recent blog post with more details:
[http://peterlyons.com/problog/2015/02/osx-development-
setup](http://peterlyons.com/problog/2015/02/osx-development-setup)

~~~
JimDabell
> I don't think you will find multiple OSX user accounts viable/enjoyable. OSX
> puts a lot of important preferences (keyboard/mouse settings for example)
> within the user account, so you will end up having a nightmare keeping
> things in sync and sane.

I've used multiple user accounts for years and I found multiple user accounts
very useful when there are clear separations between projects (e.g. multiple
freelance clients).

The settings you refer to are the kinds of things that belong in your dotfile
repo. I can set up a new account and import all my settings in a matter of
seconds this way – not a nightmare at all.

> I've lately started using project-specific instances of chrome (created with
> the chrome SSB script). This lets me keep lots of tabs separate and easily
> pause work and resume later

This is what multiple user accounts are for, except they work with all
applications, not just Chrome.

------
busterarm
I use pkgin on my Mac instead of brew, but that all doesn't matter much since
I do everything in VMs with Vagrant like most others here.

Definitely don't use your Mac in single-user mode though. Not that complicated
to set up.

------
halayli
I use vagrant + virtualbox (runs ubuntu via vagrant setup) + ansible to
bootstrap the VM.

I've had this setup for 2 years now. No issues and I get to use sublime to
edit files locally while they are shared with the VM.

~~~
somewhatoff
I do the same, but I've had trouble with the overhead of virtual machines
(admittedly on an older laptop). Have you not found this to be a problem at
all?

As deployments get simpler and the usefulness of Ansible for server config
declines, I'm thinking about abandoning the VMs and going back to running
things in OS X.

~~~
falcolas
> Have you not found this to be a problem at all?

Not myself. The VMs are never doing anything so taxing that they incur
significant overhead. I can regularly keep 3-4 running concurrently without an
issue.

> usefulness of Ansible for server config declines

I don't ever see this being the case. Configuration is becoming more
challenging, not easier. Even if you use a tool like Docker perfectly for all
of your services (which is ironically very hard without some kind of CM tool
beside dockerfiles), you still have to: install packages, change configuration
files, run commands, enable services, change permissions, change firewall
rules, modify DB users, manage SELinux, setup log file rotation...

Servers are hard to set up and maintain in a coordinated fashion without some
kind of CM tool. And while PAAS providers can handle quite a few lightweight
services without requiring you to use any CM tools, there comes a point where
they no longer scale the way you need them to, and you're back to provisioning
VMs or even bare metal.

------
amalag
Everyone is suggesting VM's but I found them far too much of a pain. Homebrew
has been able to install all databases and other dependencies for me.

~~~
von_tenia
I really like the idea of a VM on mac OS too, but recently I've been
experiencing nothing but trouble... I use to develop on a Ubuntu machine and
having everything running natively, then I started to work from a co-working
space, so I setup my Mac with Vagrant, Virtualbox, Ansible (for provision), to
run my Django app, and after that I noticed that all my browser calls to the
local development server were taking between 1 ~ 5 seconds (with tons of
involuntary context switches in the debug toolbar), when they take 300 ms on
my Ubuntu machine... I've heard that last Mac os has trouble with DNS, maybe
that's what it is but I don't really know what to do. So as much as I like how
clean it is to build a VM and separate it from the rest of your system, the
overhead and the network latency is too much for me, I'll stick to installing
everything with brew and virtualenv locally.

~~~
coldtea
Search "Mac fix DNS" and you'll find what to do.

Here's an example: [http://arstechnica.com/apple/2015/01/why-dns-in-
os-x-10-10-i...](http://arstechnica.com/apple/2015/01/why-dns-in-
os-x-10-10-is-broken-and-what-you-can-do-to-fix-it/)

------
bensummers
Use one VM per project, not Mac OS X. Unless of course you're deploying on Mac
OS X.

Use snapshots and switch between them when disk space becomes an issue.

The big advantage is that, either through careful notes or configuration
management, you'll actually be able to recreate your development environment
in the future.

~~~
keslag
Even if you're deploying to mac, you should use a mac vm. If you manage to get
a buggy or corrupt package, it's much easier to revert to a snapshot or
reprovision a vm than to reprovision your machine.

------
BrandonBradley
In regards to Python and Ruby (on Rails), have you found the tools pyenv and
rbenv (or rvm)? Node also has a similar tool, nvm. These all allow you to
manage separate version of languages and sets of package dependencies. I have
found them invaluable in keeping concerns separated.

I lean more towards local installation for software that can handle multiple
applications/connections from one install (e.g. Postgres) unless I'm preparing
my staging environment. Sometimes I use Docker containers for local services
(e.g. ZeroMQ) while developing so I don't incur a large overhead for every
service my application requires. VMs are used for staging.

I follow this pattern on Linux and OSX.

~~~
tonyarkles
I tend to agree. Most of my web development work lately has been with Rails,
although a bit has been with Node, and a bunch in Python in the past. Rbenv is
wonderful for managing different versions, npm takes care of local dependency
installs quite nicely, and virtualenv solves the problem for Python too. I
generally just install a local copy of postgresql and redis, and I'm good to
go without having to mess with a bunch of different VMs and things like that.

------
err4nt
It is interesting to see everybody using VM's and containers.

Personally I have a web server I do all my work on, so I can get to that from
my mac over: http, ftp, ssh, and vnc.

I do all my work online so I can easily point any device (or ask a friend with
an exotic device to click a link to test something) and I can also work from
any device with an internet connection.

This setup has let me be flexible, travel, work, and get things done for the
past two years. I highly recommend a dev environment thats also already online
so when your laptop lid is shut, your ability to work isnt!

~~~
baby
That's what git is for, I don't see how a webserver could replace several
vagrang boxes

------
jdefr89
Remember, OS X is a UNIX based operating system. Most of the best practices
that apply to say an operating system like Linux also apply to OS X! All my
UNIX configurations are somewhat the same and this allows my workspaces to be
uniform regardless of the specificity of the underlying OS (I mostly use OS X
and Linux!). I think you need to tinker and find out what work environment
suits you best, and its not a static situation. As you go on you will change
and tweak things, thats the beauty of it all!

------
mathgeek
In my opinion, learn to use boot2docker and just spin up each dev environment
with its own containers as you need them. Automate everything so that you run
one command to switch between projects.

------
binaryanomaly
I installed Ubuntu as a second OS since lots of the linux open source stuff
just does work much better natively than with homebrew.

For server stuff I would use docker. For docker it's the same story, linux
native is better than OS-X with boot2docker.

If you need a lot IDE's then OS-X might be the better choice since retina
support is not yet as good on Ubuntu. On the other hand Sublimetext is perfect
on linux with retina.

------
robmccoll
Is the prevailing opinion then that OS X really just isn't a good development
environment? Seems like most of the suggestions so far are "install one or
more Linux VMs". As someone who develops on a MacBook Pro everyday, I know I
definitely fall in the Linux VM camp.

~~~
JimDabell
No, it doesn't matter what platform you are developing on or deploying to, if
you are working on server-side stuff, use a VM.

It's not about needing tools from Linux, it's about keeping your development
environment and your deployment environment separate. Otherwise all sorts of
unwanted dependencies can creep in and it's difficult to reproduce the correct
deployment environment outside of your development environment. If you manage
your deployment correctly from the start, it's a hell of a lot easier.

For instance, if you install a web server in your case-insensitive development
environment, write a load of code, then deploy to a case-sensitive deployment
environment, then you may inadvertently introduce errors because you got the
case wrong somewhere in your code. You introduced a dependency upon a
development environment property that wasn't present in your deployment
environment and things broke.

The environment you write code in and the environment you have to execute that
code in are often very different things. Mixing them up is bad news – that's
where virtual machines help you out by keeping the two separate.

------
tmikaeld
Vagrant + provision.sh scripting is as simple and powerful as it gets.

