Well, it is possible to run Emacs in batch mode from the command line. Therefore you could have someone create the files as documentation, with instructions on how to run them as a single command.

I haven't tried this specifically with org-babel, and as other commenters in the thread state, Terraform/Ansible may not lend themselves to org-babel quite so easily, but it's certainly possible. Although maybe not worth the effort unless you really push hard for a team to document their infrastructure code in this way.

I have used emacs with make for this purpose. It works, but the main issue is white space. Any language that has significant white space is liable to break in org mode, and a ton of devops tools are python based, or python like.

I've been using guile and noweb, with a tangle I wrote myself, for literate devops on top of Guix and it works better than anything else I've tried.

That's really cool, do you have any public examples of the guile/guix code?

If you look at Emacs/org-babel as a tool, why is it useless for professional use-case? It is just like saying: it is too much for people to learn to use Rstudio/Shiny, yet this is frequently a go-to tool in the scientific community.

Why would it be useless for non-Emacs users? It's an integrated tool, just like any other tool which you learn to use. You can use it for this purpose while you use some other editor for other tasks.

You don't have to use Emacs for everything just because you use a certain application of it.

This isn't a system you'd deploy and expect others to maintain. It's a system for developing your playbook and Ansible / Puppet / etc configurations.

Emacs is absolutely suitable for the use case of a professional developer writing these things.

The literate programming notebook approach is very interesting. Better IMO is to reverse it and write copious comments throughout an idempotent script that you can continually edit and re-execute.

In either case, the final product that you share with others are your notes and an actual deployed configuration for a real system, not a config file for an IDE.

So your point is, that org mode is just inside one tool and therefore one cannot expect everyone else on the team to learn it? I think we can make the same argument for every single tool out there, like one specific IDE or whatever you have. It's just a question of how many people already use Emacs on the team, to make a democratic decision. Or is there some criteria, by which I can sort tools into 2 camps, "OK to force upon coworkers" and "not OK to force upon other coworkers"?

I suspect a mandate to use Org could be counter-productive.

One of Org's unique advantages is the pliability it has by virtue of running in Emacs. I doubt whether someone who was forced to use it would have the intrinsic motivation to climb the notoriously steep learning curves for both Elisp and Emacs. Subtract Elisp (and with it, the ability to do any debugging or customization) and you're left with stock Org mode running in an inferior text-editor.

Maybe stock Org is still enough of an improvement over Markdown that it's worth the overhead of learning Emacs, but I'd have a hard time making that pitch to my coworkers.

Someone tried to liberate Org from Emacs by writing a parser in Rust (see previous discussion on HN [1]), but it looks like the project died unfinished [2].

[1] https://news.ycombinator.com/item?id=19660349

[2] https://github.com/org-rs/org-rs/issues/41

Yeah, a jupyter-style solution is much more accessible IMO