org export processes code blocks even if located in noexport headline

Question

EDIT 1 : a more simple use case

For this org file content:

* Headline 1 
  - Something to export

* Headline 2      :noexport:
  #+begin_src python :results none :exports none 
  def foo():
      pass
  #+end_src

A simple html export (C-c C-e h o) leads to a processing of the python code block event if it is located in a noexport section: org-babel-exp process python at position 116...

Since I have hundreds of code blocks under non exported headlines, this leads to non useful long processing times. Is it possible to avoid this ?

Initial Question:

I have the following problem: I use a selective export with tags thanks to the following code:

#+name: myexporter 
#+BEGIN_SRC emacs-lisp
(defun myexporter (tags filename)
  (let 
      ((org-export-select-tags tags) (async nil) (subtreep nil) (visible-only nil) (body-only nil) (ext-plist '())) 
      (org-export-to-file 'html filename async subtreep visible-only body-only)))
#+END_SRC

#+name: selectiveexport
#+BEGIN_SRC emacs-lisp :noweb yes 
<<myexporter>>
(myexporter '("bar") "bar.html")
#+END_SRC

This code enables to select all sections with tag :bar: and export them to an html file called bar.html.

My problem is that when I call the selective export all code block are systematically processed (and I have a lot in my file which makes the selective export quite slow).

For example, with the following org file

* Test :bar:
  - Bla, bla

* Foo       
  #+name: foo
  #+begin_src python :results none :exports none
  def foo():
      pass
  #+end_src

the selective export leads to the following messages :

executing Emacs-Lisp code block (selectiveexport)...
org-babel-exp process emacs-lisp at position 21...
org-babel-exp process emacs-lisp at position 337...
org-babel-exp process python at position 796...
Saving file [...]/bar.html...

My problem is the org-babel-exp process python at position 796 that I would prefer not to be executed. I precise that it is executed even if a :noexport: tag is assigned to section Foo.

Is it possible to avoid this processing step ?

Answer 1

The reason that org-babel evaluates code blocks in :noexport: sections is that it does not know what depends on what and makes the worst-case assumption that any code block results you choose to export depend on every code block in the file. It's not an unreasonable assumption: presumably you chose to put all these code blocks in the same file exactly because they all work together to produce the results that you want to see.

But since the user might know better, there is an option to prevent evaluation of a code block on export, by using the eval header argument:

#+begin_src python :eval never-export :results none :exports none

See the Exporting Code Blocks section in the manual, particularly the last three paragraphs:

To stop Org from evaluating code blocks to speed exports, use the header argument ‘:eval never-export’ (see Evaluating Code Blocks). To stop Org from evaluating code blocks for greater security, set the org-export-use-babel variable to nil, but understand that header arguments will have no effect.

Turning off evaluation comes in handy when batch processing. For example, markup languages for wikis, which have a high risk of untrusted code. Stopping code block evaluation also stops evaluation of all header arguments of the code block. This may not be desirable in some circumstances. So during export, to allow evaluation of just the header arguments but not any code evaluation in the source block, set ‘:eval never-export’ (see Evaluating Code Blocks).

Org never evaluates code blocks in commented sub-trees when exporting (see Comment Lines). On the other hand, Org does evaluate code blocks in sub-trees excluded from export (see Export Settings).

EDIT: the org-babel-exp process... messages you are getting are not going to go away by using :eval never-export. Babel always has to "process" the code block to at least find out what the headers are telling it to do. But the code block is not evaluated. Try this to convince yourself that that is the case:

* Headline 2 :noexport:
  #+begin_src python :results output :exports results :eval never-export
  import time
  def foo():
      print('foo')
 
  time.sleep(10)
  foo()
  #+end_src

Try exporting with and without the :eval never-export header. Without it, the export will take 10 seconds; with it, the export is instant.