Support local config.yml for team(s)?

[kevinquillen]

Recently I created a yeoman tool to generate config quickly for either new projects or existing project needing a VM to use:

https://github.com/kevinquillen/generator-drupalvm

Assuming you did 'yo drupalvm' from the project root, the directory structure would be:

Project
---- docroot
---- tools
------- drupalvm

I tend to follow how Acquia would scaffold a site for you, so that generator does change some minor things in the config.yml template (such as naming the folder docroot instead of 'drupal').

From here you can commit it into the project. Local paths are set up to be relative to the root, which should work for anyone running on Windows or OSX/Linux.

The one caveat is what if someone needs to make a specific change, like VM memory, or sync type to rsync (since Windows NFS sync support is spotty)? Its not a change we would want committed back to the repo.

The only way around this I could think to do, was to edit the Vagrantfile and add this line:

if File.exist?("#{dir}/local.config.yml")
  vconfig = YAML::load_file("#{dir}/local.config.yml")
else
  vconfig = YAML::load_file("#{dir}/config.yml")
end

Then, add local.config.yml to .gitignore. This would allow someone to tailor the config, in case they need to, without changing the actual default VM configuration - which in my opinion the shared version should be the 'as close to production as possible' version. But I can see where folks on different operating systems or machines with varying levels of horsepower may need to tone it down, without affecting others.

My overall goal is to make it easier for the less technical to either get started or adapt their environment. Internally it has been successful so far, but this is the last hurdle - at least for now.

[geerlingguy]

Closing this in favor of #305 - let's continue the discussion over there, as I think it would be good to see how people are using it today, and how they want to use it in the future.