How would you sell dhall to a python / ansible team?



I would like to get a python / Ansible team onboard with dhall and I would appreciate any suggestions you would have to persuade them.

The context is the Zuul project that is going to evaluate Kubernetes Operator and Helm to deploy their CI/CD engine.

I would emphasize the advantages of dhall to the Zuul team; I would explain that the main barrier to entry is understanding functional programming and that one needs to learn concepts such as currying or pure functions to fully grasp dhall’s advantages. Then, I would say that with such programmable configuration language, one could do powerfull things like generate configurations for multiple systems, for example, the Operator I wrote here can be deployed with Kubernetes, but also Ansible or simply a docker-compose like shellscript.

Please feel free to leave your suggestions below.



@tristanC: The general advice I would give is to read Crossing the Chasm, but I can summarize some stuff relevant to your situation.

First, here is what will not convince a mainstream programmer:

“Dhall is the technically superior solution for this specific project”

Instead, what they want to hear is something along these lines:

“Most teams out there having the same problem as us are choosing Dhall. Everybody is using Dhall these days. I’m always hearing good things about Dhall.”

In other words, they are looking for safety in numbers. For example, that’s probably why they picked Python and Ansible in the first place.

If they don’t perceive Dhall to be the premier solution for their class of problems, then do not try too hard to sell them on Dhall. Trying too hard to convince them will only turn them into negative references for Dhall.

As a rule of thumb, most people have already made up their minds on what class of tools they want to use and have emotional attachments to those choices. Good design and marketing is about inhabiting that space of emotional attachments long before the actual technical decision is made.

If they don’t already have warm and fuzzy feelings about Dhall right now, it’s unlikely that rational debate or comparisons of technical merits will get them to switch their allegiances on short notice. Those sorts of emotional attachments take time to build and to change. The best you can do is give them opportunities to experiment and play with Dhall over an extended period of time and ensure that whatever brief interactions they have are positive, polished, and of high quality so that they can intuitively feel that Dhall has a mature community and ecosystem behind it.


@tristanC Don’t turn Dhall into a solution that’s looking for a problem. Find a problem that they have with their current setup, show how Dhall solves that problem, and then explain why trying to solve that problem without Dhall is a pain in the neck.

By us, it was pretty easy to show why shipping complete YAML files, and then trying to write on top of them, was a dumb idea. Explaining to people that they could ship functions blew their minds.

@Gabriel439 thanks for reminding me that I needed to pick up a copy of CtC :slight_smile:


Thank you so much @Gabriel439 and @ari-becker for the suggestions. I find it hard to apply CtC for something like Dhall and it’s difficult to know it’s current positioning, whole product, …
Thus I really appreciate your recommendations. I wrote this problem description and how Dhall helped us:


Based on my experience (we use ansible with dhall experimentally at work), the main appeal of Dhall is that you don’t shoot yourself in the foot because of YAML syntax things I don’t understand. It also avoids various things where you type becme as become and only realize halfway through a run.

Unfortunately, the way YAML+ansible is set up (use YAML with templates in various places when functions would do and are on more solid theoretical foundations), it is hard to replace - using Dhall to template YAML containing templated Jinja is finicky!


The Zuul team is already using the YAML syntax extensively with the & anchors and << merge operations along with the ansible-lint tool, which can already reduce quite a lot the chance to shoot yourself in the foot. Though ansible-lint can be annoying sometime, and Dhall would let you fix both issues at once (YAML syntax oddities and ansible typos). Thus I also started some work on a dhall-ansible package.

With regards to templating yaml configuration (inside a playbook or kubernetes secret), I am having some success with the JSON.render function, though this requires extra code to convert to JSON.Type.

Also with the recent addition of the to-directory-tree command, Dhall could also help a lot with scaffolding, for example the operator-sdk needs configuration content (e.g. the service account name, or the api group) to be set in many files, which is quite tedious to maintain.


I am happy to report positive feedback about using Dhall from a python team.

The main challenge was to develop a Kubernetes operator that features optional services and custom configuration. The legacy implementation was using Ansible with Jinja templates, and this resulted in such problematic expressions all over the place:
{% if merger.count is defined and merger.count > 0 %}{{ services | union(merger_services) }}{% else %}{{ services }}{% endif %}
Dhall solves this problem by using a safer grammar where we can handle complex scenarios early on, resulting in maintainable resource descriptions.

The opposing argument was that we could use the golang operator-sdk or the python kopf framework instead, and that would have been a fine solution to solve that particular Kubernetes operator challenge. Though using a general purpose configuration language was also a compeling argument as Dhall can be used to solve other problems that are not bound to Kubernetes.

The team eventually agreed to give Dhall a try. Here is the documentation that explains how it fit in the zuul-operator:

Thanks again for the very helpful suggestions :slight_smile: