Support LookML generation from Python objects

[joshtemple]

It would be useful to have a dump function similar to other Python packages like json and yaml. This function would accept a Python object and would serialize it into a string of LookML, the exact opposite of the load function.

In my opinion, lkml should not be responsible for generating LookML that is always functional in Looker (e.g. valid property names). The only requirement is that the generated LookML can also be parsed successfully with lkml.

[joshtemple]

The serializer should descend recursively through the Python object, outputting strings to a string buffer using the following rules:

• Dictionaries should be serialized to LookML blocks
  • Every dictionary must have a name key so we know what to call the block
  • The name key will be popped and used to name the block
  • Dictionaries with valid plural keys (e.g. dimensions, dimension_groups) and list values should be split up into multiple blocks and not considered sets
• Keys and values should be serialized to LookML keys and values
  • sql keys (including other valid expression block fields like sql_table_name) should have a space and ;; appended
• List values should be serialized to LookML sets
• Boolean values should be serialized to yes and no

A major challenge: I have no way of knowing from the object which values in pairs or sets should be serialized as quoted literals (label: "Field") vs. unquoted literals (hidden: yes). This is probably something the serializer should be aware of rather than something the user would have to specify via some other key. This would require me to maintain a list of all pair keys with quoted values or set values, which is tedious and prone to breaking with Looker updates.

[jamescurtin]

One potential avenue to explore re: quoted vs. unquoted literals--does Looker expose their parameter documentation via API? The web based documentation seems to contain the necessary information in the Accepts section (e.g. this one for labels) to programmatically update QUOTED_LITERAL_KEYS.

If the API solution was available, you could imagine using a scheduled CircleCI workflow to check for new keys and the Github API to create a PR adding the new parameters. This could almost eliminate the maintenance hassle.

[joshtemple]

It's an exciting idea, but as far as I can tell, Looker does not expose any kind of documentation resources via their API.

I've run tests against my trove of public GitHub LookML and fixed all issues with quoted keys, so I'm confident that QUOTED_LITERAL_KEYS currently covers at least 95% of the fields being used. I'm optimistic that between me paying attention to Looker release notes and users submitting issues, I can cover the maintenance fairly easily.