0

I have developed a workflow for batch-export of org-mode files, and have come across an issue in which execution halts when using a python session. I'm using emacs 28.1 on MacOS 11.6.5 with Python 3.9.5.

Here's a minimal org-mode file (python-session.org)

#+PROPERTY: header-args:python :exports both :eval yes :session

#+begin_src python :results output
import sys
print(sys.executable)
print(sys.version)
var = "from the first block"
#+end_src

#+begin_src python :results output
print(var)
#+end_src

..and some minimal code to export on batch mode

(let* ((infile (car (last command-line-args)))
       (outfile (concat (file-name-sans-extension infile) ".html")))

  (find-file infile)
  (org-mode)
  (org-babel-do-load-languages
   'org-babel-load-languages
   '((emacs-lisp . t)
     (shell . t)
     (python . t)))

  (setq org-confirm-babel-evaluate nil)
  (setq org-babel-python-command "python3")
  (setq python-indent-offset 4)
  (setq python-shell-completion-native-enable nil)
  (setq python-indent-guess-indent-offset t)
  (setq python-indent-guess-indent-offset-verbose nil)

  (org-html-export-as-html)
  (write-file outfile))

Here's the command to perform the export (and the resulting message):

% emacs --batch --load minimal-export.el --kill -- python-session.org
executing Python code block...

At this point the process hangs and must be interrupted.

The above command results in an exported html file when the :session option is removed from the first line of the file:

% emacs --batch --load minimal-export.el --kill -- python-session.org
executing Python code block...
Code block evaluation complete.
executing Python code block...
Babel evaluation exited with code 1
Code block produced no output.
Cannot fontify source block (htmlize.el >= 1.34 required)
Cannot fontify source block (htmlize.el >= 1.34 required)

Any ideas on how to troubleshoot further?

user2040585
  • 1
  • FWIW, I have no problem doing the above with `GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4) of 2022-02-12`, so it may be a bug in Emacs 28.1. BTW, when I say no problem, I mean there is no hang. But the output of the Org Babel source block is messy; in particular, it is not an exact copy of what you would get when you run the program from the command line. For that reason alone, I avoid python sessions in Org Babel. – NickD Apr 24 '22 at 00:07
  • I also have no problem with Emacs 27.2 which is the version that comes with my Linux distro (Fedora 34): no hang; same output problem as described above. – NickD Apr 24 '22 at 00:10
  • I misspoke about the output: it is exactly as would be expected in both cases. – NickD Apr 24 '22 at 00:15
  • 1
    Thanks @NickD - it occurred to me to check on another OS, and I can't reproduce this on Ubuntu 20.04 with emacs 28.1... so apparently this is a MacOS-only problem. I wonder if anyone else can reproduce on a mac. – user2040585 Apr 24 '22 at 02:38
  • I can confirm same behaviour with Emacs 28.1, MacOS 12.3.1 and Python 3.10.1 – Ian Apr 25 '22 at 13:24
  • I run the file ```python-session.org``` in GUI Emacs and also freezes there, but show the warning: ```Your `python-shell-interpreter’ doesn’t seem to support readline...```, which is true for me, I don't have ```readline``` installed. – Ian Apr 26 '22 at 09:54

2 Answers2

0

Ok, after learning a great deal about how to (clumisly) trace elisp code, I identified this as a bug in prompt detection in python.el: apparently the startup message for the python interpreter is not being recognized. Launching the interpreter with python -q suppresses the prompt, but the variable python-shell-interpreter-args does not appear to be respected. So the brute force solution is to advise the function that sets up inferior-python-mode to add -q:

(defun advised-python-shell-make-comint (orig-fun &rest args)
  (setq args (append '("python3 -q") (cdr args)))
  (apply orig-fun args))

That's it. Not a great long term solution, and hopefully this will get fixed in python-mode.

user2040585
  • 1
0

I was running into the same problem.

macOS 10.15.7, GNU Emacs 28.1, Doom Core 3.0.0-dev, Doom Modules 22.07.0-dev

And using pyenv with the +pyenv Doom Emacs setting.

My process was to run org-babel-execute-buffer(C-c C-v b) which let me C-g out of the 'executing python codeblock...' status. And then all the following codeblock executions with RET and C-c C-c ran correctly.

I have #+PROPERTY: header-args-python :session in my header, which I always ran separately from the blocks. So in short, (C-c C-v b) fixed it for me.

Hope this helps.

EDIT: Forget about my original answer, I think it was a coincidence. This really fixes it for me: rename the session to the current python process' buffer. So if the buffer is named "Python", set the session name like :session Python

Alberto Valdez
  • 1
  • 1