With the Org file:
| #+BEGIN_SRC python :results silent :exports results
| test = '1'
| with open('test-a.log', 'w') as f:
| f.write(f'Test {test}a\n')
| with open('test-b.log', 'w') as f:
| f.write(f'Test {test}b\n')
| #+END_SRC
| Test, part A:
| #+INCLUDE: "test-a.log" verbatim
| Test, part B:
| #+INCLUDE: "test-b.log" verbatim
and test-a.log and test-b.log not existing, on the first
(unsuccessful) export, the error:
| org-export-expand-include-keyword: Cannot include file /tmp/test-a.log
is displayed. However, if these files already exist, they
are included as is, and /after/ that inclusion, the Python
source block is executed.
This means that if one changes "test = '1'" to "test = '2'"
in the Python source block, one has to export the Org file
twice to see the changed result in the export.
Technically, this is probably the "correct" behaviour as
otherwise the order of execution would be very hard to de-
termine.
But why did I spend a few hours debugging this before final-
ly understanding Org's mode of operation? The first sen-
tence of the documentation in "13.4 Include Files" reads:
| During export, you can include the content of another file.
| […]
I'm not a native speaker, but the word "during" drew the
mental image for me that, when exporting, Org starts at the
top of the document, reads through to the end, and if en-
counters a "#+INCLUDE:" statement /during/ that, it includes
the referenced file at that point.
Now the Org manual is already beset with examples that look
as if someone complained about something not being document-
ed somewhere, and then someone adding one sentence just that
somewhere, so I don't want to add to that with "just a quick
fix".
But I do think it would be helpful if the "order" while ex-
porting would be documented in a meaningful way.
