I’d like to have a tool that runs and writes some files to _build and then dune would Just Know™ that the tool has produced promotable changes. Is it possible? It’s not documented in readthedocs (or it’s not easily findable there) but it seems like potentially something that’s possible.
(I don’t want to run my tool from dune.)
At some point there was a feature that would copy all possible “promotions” out of a rule’s sandbox (I’m simplifying some things), but it was removed as it was never used. In principle, we could reintroduce it back but this “feature” has one dreadful side effect: multiple rules can now produce promotions for the same source file. As you might imagine, it’s hard to handle that sensibly and we never even bothered to try.
If you’re really motivated you could revive this feature and hopefully add the missing safety guard rails.
I don’t really understand your message but it’s likely because I don’t understand some of the internal workings of dune. I’ll try to read up on it a bit more.
To make things possibly clearer, I’m thinking about having an external tool inform dune that a fixed/improved version of a file is available. E.g., an external tool calling an as-of-yet-unavailable subcommand like dune promotion add path/to/file/in/repo /tmp/fixed-it-for-you.
I understand from your message how this isn’t sound if you offer promotion for files that dune itself can create a possible promotion for, or if multiple promotions are offered for the same file. I’d have to think about that.
While working on zanuda linter an experiment was made which creates .patch file with source code changes, that could be applied later via specialized program. (At the moment the experiment is not very mature…)
In which direction integration with dune would be better than the naive approach?
It isn’t generally possible (like, you can’t specify a tool that would read all source files and edit them in some way), it is possible to promote the output of a rule back to the source tree. So depending on what you want to plug in this may or may not be a feasible choice for you.
Also, in some cases you could specify your files as dialect and specify a formatter, then dune fmt will promote the processed files back to the source.
I like this idea of hijacking the dialect mechanism. However, it requires calling dune which has a relatively high upfront cost because it requires scanning the entire project for dune files to begin with, and then resolving the fmt alias.
Still, keeping that in my bag of possible tricks, maybe for a smaller repo or a different project.
the main reason I want to use dune’s promotion system is that
dune promotion … commanddune, have it installed, etc. so I don’t have to get a new tool in the dev loopi’ll try to find a similar tool or maybe build the simplest one on top of .patch files
Your comment suggests that you understand the issue of having more than one build actions producing such promotions for the same file. The issue isn’t deeper than that and it could certainly be addressed with a little engineering effort. It just needs somebody to roll up their sleeves 
It’s mostly the technical details about “the possible promotions being copied out of a rule’s sandbox” that I don’t (yet?) understand. I might end up looking into that at some point, don’t know yet.
The code removed in this PR might be a good reference for you:
But instead of copying things from the sandbox to the source, you should just use promotion api to register your promotion when you find a file matching a particular extension. E.g. foo.ml.corrected should register a promotion for foo.ml. With a little prompting, you should get something running.