lbovet

Dhall is awesome and rooted in the solid ML line. I wish pure functional programming langs were significantly growing in the industry. It would show signs of maturity but it is still currently a high-hanging fruit for many and traction is diluted in the impression of hobbyism or academism. What can we bring for those dealing with YAML everyday? Hard to tell them "switch all your stuff to X". Easier to tell them "you can iteratively add functional expressions to your YAML". That's the point of Yglu. It's not about proposing a better Dhall or Jsonnet. It is about proposing better YAML-native tooling.

Yes, I liked the idea of ytt and after playing a bit, I felt that we could do YAML processing in some more YAML-native way.

YTT fulfills its mission, but I wanted to explore a more generic approach and have the loading of libs and values using the same mechanism. Also, allowing the reusable parts to be written in YAML and not only in the additional programming language.

I aim at bringing some ideas in this area and if they make sense, I am happy to see them live, be it in Yglu, YTT or any other tool.

Also, the fact that building Yglu was fast because of YAML parser and YAQL were already existing made me explore on my own, rather than developing these ideas in modifying or coding YTT libs, what I first imagined.

About the readability, I also don't see an argument here. !? vs. #@ does not matter a lot. It only matters that !? is already understood by the YAML parser as a tag, avoiding me to write a parser (I would not have started this work). The cool thing is that tags can also be used in mapping keys.

I will rephrase the "single source for template values" into something that gives better credit, because I really meant that import mechanisms should be the same for values and other stuff (libs, functions, ...). And aslo not only as overlay.

Thanks for the inspiration and let's continue to try and relieve the YAML pain around us.

I tried the recipe and noticed that create with -v also creates a volume and copy the image content. Docker documentation also states that it is the same as VOLUME in Dockerfile. So what is the advantage? The long copy time is still there ...