Clarify or remove use of fixture data in settings.json

[aaronjudd]

The problem:

@prinzdezibel "Ouch! Wasting several hours to realize that some (not all?!) values in settings/*.json are used as fixture data to populate DB (PAYPAL-REST-Credentials). And I was thinking, these are values that are read every time I do a server restart.. This is not good IMHO.
I would expect runtime app configuration values there..
no fixture data.
I was changing values over and over with no effect.."

Possible solutions:

understand the confusion, it’s a practice many of the meteor packages use, but you are correct it’s probably either a) something we should remove entirely (and make it a best practice to not do this), or b) something we should document better. I would lean towards removing any kind of fixture data (but then you’d need your own fixture data when testing in private/data) or c) creating a fixtures.json that is specific for package fixture data (versus private/data which would not be modified for the average user) or d) add a fixture object to settings.json and move fixture related into object (plus docs). I’ll add an issue for discussion

[prinzdezibel]

For the average shop admin/technician it is totally acceptable (and probably easier) to force him do initial database configurations through an Admin-UI and NOT confuse him with configuration file settings that are used only in certain cases (e.g. when running meteor reset, when database is empty, etc..)

The value of the existing mechanism lies in the ease of development for reaction commerce core developers. Because they can do meteor reset without loosing DB configuration. But because they are very savvy with the source I would absolutely not hesitate to force them to put their own private configuration to private/data like all the other (more universally used) fixture data.

My proposal: Drop data fixtures from settings completely and give developers a way for maintaining individual fixture data.

[aaronjudd]

I think this goes hand in hand with intent in #239 and #238

I agree, with your assesment. I think we started using settings.json long before we had the fixtures data. It might be useful to add a fixtures method for the app level as well though, since not all developers are working in core, (such as, I'm just writing a payment package).

[useralive003]

root@dev-app-server:~/reaction# ./reaction
Starting Reaction using '/root/reaction/settings/dev.settings.json'.
[[[[[ ~/reaction ]]]]]

=> Started proxy.
=> Started MongoDB.
Unexpected mongo exit code null. Restarting.
bin/run: line 30: 7730 Killed meteor $CMD --raw-logs --settings $DEVCONFIG $ARGS