Document our desire to move templates into the respective "parent" gems

[asmith-mdsol]

If "parent" gems provide their own templates, gems like dice_bag-mdsol can go away. Ultimately DiceBag would hold no templates of its own but only once we had, for example, the database.yml template moved into active_record.

Requires an update to the README and perhaps the creation of a CONTRIBUTING file.

[harryw]

👍

[asmith-mdsol]

Just had a discussion with @fosdev. He wants us to properly separate concerns and move the templates we ship to their parent gems. This is fine and 100% the plan for mdsol/dice_bag-mdsol, which will become empty/obsolete because we are in control of the parent gems. For open source gems like ActiveRecord we might never get acceptance. I don't want to hold up #17 over this...

One thing that occurred to me is that we could move the templates out into their own gems (pending a move to their parent gems) like "dice_bag-active_record" and "dice_bag-newrelic", or perhaps gather them in "dice_bag-rails" or "dice_bag-templates" if we think the first approach is too granular.

[fosdev]

I think a "dice_bag_templates" gem or something like that for configuring things we don't control but have an opinionated approach to configuring makes sense. We do it once for external gems and that becomes our "way" for the platform and is managed in that gem. Then the dice_bag gem is consumed in our applications to generate their configurations in an opinionated way and looks for templates in a canonical way. If we want to configure external things like database.yml, we look to those other templates based on some dice_bag config file and dice bag knows how to look into the "dice_bag_templates" if the gem is in the library, etc, I presume (sorry, have not dug into the gem).

[fosdev]

@asmith-mdsol And while we are on the topic of moving configuration templates into the gems, what would be cool for local development is the ability to set default values in the templates so that we can use some switch to generate our configurations locally. So instead of storing eureka.yml.sample in my repo, I include default local dev sample data in the template in some way along the lines of the configuration email thread we talked about. Once I generate the config files (.rb initializers, whatever I presume), I can tweak them as needed.

[harryw]

@fosdev I think you've come to the same conclusion as @asmith-mdsol and I also have, separately of one another, that this approach should also provide an easy way to handle local development config, with some sensible defaults. So ideally as an engineer using Medidata services you can expect to just clone, bundle and run the build/release tasks and you have a default development environment ready to go.

On the point about separating the templates out into gems - I don't think it matters that much, but it does make me think that I would love to be able to include different templates by requiring the right files within dice_bag; so if I want all the templates I require 'dice_bag' but if I want just database.yml I require 'dice_bag/base' and require 'dice_bag/templates/active_record' or something like that. What I've written in Medistrano to control which templates are used does work, but it feels a little inelegant.