[Feature-Claim]: 3) Refactor AppConfig and EnvironmentConfiguration

[Chris Poirier]

I'll have a look at this one. 

[Sean Tilley]

Hey Chris,

Just figured I'd follow up, as it's been a little while since you've filed a claim for this item on the wishlist. Do you still want to work on it?

[Chris Poirier]

Hmmm, my email replies might not be getting through. 

In any event, I started looking into it, but got busy with paying work. Might be another week before I can devote any real time to it, but it's still on my list. If somebody else wants it in the meantime, go ahead.

Chris.

[Chris Poirier]

I started looking into it, but got busy with paying work. Might be another week before I can devote any real time to it, but it's still on my list. If somebody else wants it in the meantime, go ahead.

Chris.

On 2012-04-06, at 18:47 , Sean Tilley wrote:

> Hey Chris,
>
> Just figured I'd follow up, as it's been a little while since you've filed a claim for this item on the wishlist. Do you still want to work on it?
>

> --
> You received this message because you are subscribed to the Google Groups "diaspora-dev" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/diaspora-dev/-/QO8M8kL9xZgJ.
> To post to this group, send email to diaspo...@googlegroups.com.
> To unsubscribe from this group, send email to diaspora-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/diaspora-dev?hl=en.

[Jonne Haß]

Hey everybody,
I think our configuration file is… a mess to put it into kind words :P
I've done a first draft of a possible refactor and would like to hear what you think about it. This is mostly done from a user experience perspective with almost no regard to implementability, still I think it would be possible to implement.
Check it out here: https://gist.github.com/2375590
Thanks,
Jonne

[Chris Poirier]

Hi Jonne,

You look like you've got a good handle on this, and I'm still buried with other work. Please feel free to take this one; I'm officially backing out.

Thanks!

Chris.

[Maxwell Salzberg]

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.

[Maxwell Salzberg]

With that being said, I think there is a bunch of good ideas here that we could pull in piecewise, as we move forward in making the whole loading process better.

For example

1. reorganizing the keys to be grouped together, without the namespaces.

2. setting explicit overrides in each environments for keys which are required for that environment.

3. improved documentation

Once we nail those down, I also agree that renameing some cryptic key names is in order. Since this will require some action in terms of code and by podmins, we should do that at a later, well defined date.

-m

[Tom Scott]

Since shell environment variables are read directly, what happens when I change an environment variable while the app is running? When you change variables in config/database.yml, you must restart the server to see changes. If we were to, say, store our DB connection details in env variables, wouldn't that introduce the potential of data corruption?

- T

[Maxwell Salzberg]

Tom,

Great point.

I think for now, we are not worrying about database.yml stuff (as that is built into rails, and dealt with other ways) but the application.yml which contains a bunch of D* specific config-stuffs.

-m

[Tom Scott]

Maxwell,

I was just using database.yml as an example, because I used it to do a test on the app I work on to make sure I wasn't bullshitting. :)

- T

[Sean Tilley]

Hey Johnne,

I looked at your proposal as a starting point to work from, and I've created a gist based on the current variable names we're using in our application config file. I think a lot of the ideas you've proposed are great, and we can work with a lot of it.

I've taken the liberty to do a little restructuring and changing things around, everyone is welcome to take a look at it here.

Best,

-Sean