multi-user support?

[ecc11718]

Decide if we're going to support, besides implicit root and obviously vagrant, other users on the box. Are there common cases where other user accounts are needed for development?

If so, the chef node json should be restructured into something like this:

chef.json = {
  'packages' => [ # ...
  ],
  'user_installs' => [
    {
      'user' => 'vagrant',
      'site' => { #...
      },
      'nvm' => { #...
      } #, ...
    } #, user_x...
  ]
}

[ecc11718]

Even if we don't support multi-user, I think the json needs to be restructured so we're not doing user_installs per "lang."

[ecc11718]

Maybe that's it. Maybe we don't make the decision. We just structure the json and logic to allow for it?

[lukewpatterson]

to help keep all factors in mind, think about the existing 3rd party rbenv recipe we currently rely on. i wonder if we could consolidate/remap that.

[ecc11718]

Worst-case scenario, we might have to shoe-horn some duplications for recipes not conducive to the overall layout.

If we can "fool" rbenv into thinking it's got the chef json, great.

[ecc11718]

Better still, maybe:

chef.json = {
  'packages' => [ # ...
  ],
  'users' => [
    { 'user' => 'vagrant' },
    { 'user' => 'foo' } #, ...
  ],
  'user_installs' => 
  {
    'site' => { #...
    },
    'nvm' => { #...
    } #, ...
  }
}

[lukewpatterson]

regardless of how we handle the langs, the 'users' node is probably a keeper, aligns with 'packages' and 'symlinks' style of json based configuration