[kohlerm]

I used to manage the development environments of several hundred developers using Chef. It kind of worked, but would not very well support configuring files in the users home directory for example. Also setting up services locally needed for development (RabbitMQ, Tomcat etc) became much easier with Docker. I switched to Docker for that purpose, and most of the chef scripts became unnecessary. What the nixos package manager can easily solve is managing configuration files in the users-home (using home-manager), as well as installing different versions of different tools at the same time. You can even go as far as using direnv to automatically provide the tools (jdk, nodejs, gradle etc) when entering a given project just checked out from git.

Therefore Chef (they other tools are equivalent in my view) is IMHO not a good enough tool to manage dev environments.

[jsjohnst]

> Therefore Chef (they other tools are equivalent in my view) is IMHO not a good enough tool to manage dev environments.

I agree, but your and my definition of “good enough” is not the same as everyone else’s. These tools wouldn’t be as heavily used if folks didn’t feel they solved a problem they had.

[kohlerm]

They used to solve some problems in a way that was good enough at that time. Nowadays setting up services, where you have to take care of avoiding port conflicts, is much easier with container technology. Modifying config files in the users directory is in my experience a pain because chef was not designed to do that. You have to do all kind of workarounds to get permissions right. Just using Chef for abstracting from which package manager you use also does not fully work because package names can be different between Linux flavors. Chef also requires a ruby installation, which itself is a problematic large dependency which might conflict with another ruby version on the system.

Update: trying to install the same package in different versions at the same time is also a pain.