Jonne,
Thanks so much for your thoughts. I agree, re-organizing (and cleaning out some cruft keys) would be a worthy refactor, if only for our own sanity.
TL;DR
I want to move more configuration to the env, like this(http://www.12factor.net/config), and nesting settings makes it harder in code, so why cant we just put commented out headings in the yaml file and reorganize it?
A couple of things, off the top of my head
1. I really dont want is doing a custom loader for this type of information, as it is code I just don't want to maintain, as it really it outside of our primary goal. There are libraries that do this, and we should use them so we can worry about them worrying about use cases.
2. re: nested keys
a. while nested keys do increase readability in the yaml file itself, I think that it decreases useability in the code. Having to know where I nested what options is kind of really annoying.
b. nested keys make it harder to serialize things to ENV variables. One of the goals of the refactor I posted on the wish list was to move us closer to this idea (
http://www.12factor.net/config).
Having an application.yml that needs to be loaded every runtime makes it really hard to maintain as an open source project which is being deployed in many different enviroments. Currently, our 'array' keys are preventing us from moving to a more lightweight solution. Also,
Having to check in a .gitignored file just to push from diaspora/diaspora is a smell I'd like to work to remove.
3. As I insinuated in the previous number, I'd like to push this to be more ENV heavy, rather than yml loading heavy. This library begins to do what I am hoping(
https://github.com/laserlemon/figaro) Removing a hard dependency of application.yml to me, is a good thing that makes it easier to deploy, and requires less hacks for everyone.
Also worth noting, my wishlist item was actually more about AppConfig and EnviromentConfiguration as ruby classes, which are really f'ed up in terms of responsiblities, which checks validity of options, errors out the application if certain state is not met, as well as extending keys and creating helper methods around them. It is way too much logic for those two classes, and they should really be broken up into smaller, more testable objects.
- maxwell
You received this message because you are subscribed to the Google Groups "diaspora-dev" group.