[the_mitsuhiko]

> the ini-file configuration seems a bit strange to me(esp since it seems to be ini-files that occasionally contain python code). Why did you go with them instead of making these python classes? To allow the GUI to edit parts of them as well?

I grew to heavily dislike the idea of just executing random code to configure things. Impossible to expose to tools, even harder to reason about it. Note that these files do not contain python code at all. They just sometimes contain little Jinja templates.

The idea is indeed that the GUI can eventually edit some of these things. It also is already used for `lektor plugins add` for instance which updates the project ini file.

Lastly the reason ini over yaml is purely that this can preserve comments and doing the same for yaml is a lot more work i did not have time for :)

[crdoconnor]

>Lastly the reason ini over yaml is purely that this can preserve comments and doing the same for yaml is a lot more work i did not have time for :)

Was that the only thing that bothered you about YAML/pyyaml or were there other things you'd like to see fixed?

[the_mitsuhiko]

YAML is really quite complex. I like it in general but it's impossible to dump the data out without destroying the structure of the file (throw away comments, change whitespace, formatting style etc.)

[crdoconnor]

Did you look at https://pypi.python.org/pypi/ruamel.yaml ?

[the_mitsuhiko]

Nope. Did not see it. That's neat though. Would probably have done it differently in that case, but no real reason to switch now.

[pkd]

TOML? It was made because YAML was too complex.

[detaro]

Thanks. Yes, the code-as-configuration thing is difficult, it invites people to do very strange things sometimes.

    [children]
    replaced_with = site.query('/projects').filter(F.categories.contains(this))

(from the categories example) looked a lot like embedded code to me ;)

[the_mitsuhiko]

Since there is no SQL I'm using the expression language from the templates for queries :)