Live data from Hacker News

Ask HN: Best practices for OS X dev environments

news.ycombinator.com

21–30 of 57 posts

Re: Ask HN: Best practices for OS X dev environments

#21
post #17
post #12

Earlier quoted context omitted.

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 contentio…

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

It's called Docker.

Re: Ask HN: Best practices for OS X dev environments

#23
post #17

Earlier quoted context omitted.

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

It's called Docker.

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

Re: Ask HN: Best practices for OS X dev environments

#24
post #12

Earlier quoted context omitted.

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 contentio…

> 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. Vagrant won't install Chef or Puppet for you - your provisioning scripts need to do this. If you're seeing Chef being downloaded every single time you p…

The chef provisioner which comes as part of vagrant does indeed install chef on the target VM. To say that vagrant is not doing this is splitting hairs.

Re: Ask HN: Best practices for OS X dev environments

#25
post #18

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.

How do people find the battery life overhead? A quick test showed a Flask dev server tool 25% in a VM compared to less than 2% natively.

That would seriously restrict my ability to develop on the move or away from my desk.

Re: Ask HN: Best practices for OS X dev environments

#26
post #17

Earlier quoted context omitted.

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

It's called Docker.

Docker is not a VM and only works on Linux.

Re: Ask HN: Best practices for OS X dev environments

#27
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.

Re: Ask HN: Best practices for OS X dev environments

#29
post #24

Earlier quoted context omitted.

> 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. Vagrant won't install Chef or Puppet for you - your provisioning scripts need to do this. If you're seeing Chef being downloaded every single time you p…

The chef provisioner which comes as part of vagrant does indeed install chef on the target VM. To say that vagrant is not doing this is splitting hairs.

I've never used Chef, with or without Vagrant, but I have used Puppet.

It's generally better to have a shell script install your provisioning tool, or use a box that already has it installed, than depending on Vagrant to do anything for you.

Here's a simple example: https://github.com/puphpet/puphpet/blob/master/archive/puphp...

Re: Ask HN: Best practices for OS X dev environments

#30
post #17
post #12

Earlier quoted context omitted.

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 contentio…

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

You might be interested in my FOSS that aims to do just that: https://puphpet.com
Post reply on HN