Convert JSON config to Python

[rviscomi]

2019.json is loaded at runtime, parsed, and stored in memory on the web server. We went down this road because JSON is a convenient format for maintainability, but it's complicating the server-side rendering. This'll get worse as we build a 2020.json and so on.

I propose we ditch JSON and maintain the config directly in Python manually. I think this will simplify a few things in flight, like #557 and #398.

@bazzadp @mikegeyser WDYT?

[tunetheweb]

Don't have a strong opinion one way or another to be honest.

Would it still be a config per year (e.g. 2019.py, 2020.py)? Think that's a good thing so would suggest yes rather than directly in other code.

If we are doing a big reformat then should consider design and what else we can solve, as in #398 as you say, but also is there anything else in templates we should pull out to make translations easier and make it less difficult to maintain so many templates?

For example do we really need:

• templates/base.html
• templates/lang/year/base.html (hate that this is also called base.html btw!)
• templates/lang/year/base_chapter.html
• templates/lang/year/chapter.html

Seems like a lot to keep in sync as languages grow. Is there anyway to remove the lang/year specific ones and move some of that content into config so these can be more generic?

Probably just moving the JSON into python is a good first step, rather than trying to overreach, and then we can iterate, but worth baring in mind if designing the format of that.

[mikegeyser]

@rviscomi I have absolutely no problem putting the config in python. It seems expedient.

As an aside, I always rationalise this by asking myself 'if we change config, do we have to redeploy the whole site?' If the answer is yes, then I believe that putting it in a config file isn't really meaningful.

[rviscomi]

Would it still be a config per year (e.g. 2019.py, 2020.py)?

Yes and I would suggest that we be a bit more object oriented, where we have something like an AnnualConfig base class which we extend for 2019, 2020, etc. In the base class we can define functions for interacting with the config data.

[tunetheweb]

@rviscomi given that we have solved #398 and it seems to be working well do you still want to do this? Or should we close this issue?

We can then reopen #557 and accept that to fix #400 .

I take your point that it's complicating the server side rendering a little, and the JSON may grow for future years, but given the discussions in #634 and #638 it doesn't seem to be causing any issue at the moment. So my vote would be to close this and revisit if this becomes and issue later.

Thoughts?

[tunetheweb]

Going to close this as think 1) it’s not causing a big problem, 2) we use some of the config in the chapter generation and 3) it makes it easier to port if we ever moved off python in future.

Feel free to reopen if you disagree!