jorgenschaefer / elpy

Emacs Python Development Environment
GNU General Public License v3.0
1.9k stars 262 forks source link

comint-send-string: Process Python Internal[denoise.py] not running supress opening of python files/buffers #1819

Closed Xparx closed 2 years ago

Xparx commented 4 years ago

I got the following issue https://github.com/jorgenschaefer/elpy/issues/733 and solved it using the provided code, actually setting the lines suggested back to their defaults. However after that I get the following message every time I try to open a python file. comint-send-string: Process Python Internal[pythonfile.py] not running The file gets opened as a buffer but does not pop to the forefront in emacs for some reason.

My configuration

Ubuntu 18.04 $ emacs --version GNU Emacs 28.0.50

Result of (elpy-config)

Elpy Configuration

Emacs.............: 28.0.50
Elpy..............: 1.34.0
Virtualenv........: rpc-venv (/home/at145/.emacs.d/elpy/rpc-venv)
Interactive Python: jupyter-console 6.1.0 (/home/at145/.emacs.d/elpy/rpc-venv/bin/jupyter-console)
RPC virtualenv....: rpc-venv (/home/at145/.emacs.d/elpy/rpc-venv)
 Python...........: python3.7 3.7.5 (/home/at145/.emacs.d/elpy/rpc-venv/bin/python3.7)
 Jedi.............: 0.17.1
 Rope.............: Not found (0.17.0 available)
 Autopep8.........: 1.5.3
 Yapf.............: 0.30.0
 Black............: 19.10b0
Syntax checker....: flake8 (/home/at145/.emacs.d/elpy/rpc-venv/bin/flake8)

Warnings

Options

Elpy configuration in my init.el

(when (or (el-get-package-exists-p "elpy") (require 'elpy nil 'noerror))
  (elpy-enable)
  (add-to-list 'company-backends 'elpy-company-backend)
  (setq elpy-rpc-python-command "python3.7")
  (el-get-envpath-prepend "PYTHONPATH" default-directory)
  (setq python-shell-prompt-detect-failure-warning nil)
  )
(when (el-get-package-exists-p "elpy")
  (setq my-default-virtualenv "py37_intel")
  (if (member my-default-virtualenv (pyvenv-virtualenv-list))
      (pyvenv-workon my-default-virtualenv)))
galaunay commented 4 years ago

From the result of elpy-config, it looks like you have the same issue than #1379

Is it better with (setq elpy-rpc-virtualenv-path 'current) ?

Xparx commented 4 years ago

I have implemented that fix but it doesn't solve the issue of leaving the buffer in the background.

galaunay commented 4 years ago

Is there an error raised when opening a python buffer ? If so, what is the traceback obtained with M-x toggle-debug-on-error ?

Xparx commented 4 years ago

I get no error message. What happens now is I get this message in the Message buffer: comint-send-string: Process Python Internal[<PYTHON_FILE_NAME.py>] not running

That's after implementing the "fix".

galaunay commented 4 years ago

I see you are using the jupyter console. Are you using the configuration specified in the doc ?

If the doc does not help, Elpy uses (run-python (python-shell-parse-command) nil t) to start the python shell. You can already check if running it create a shell or not.

Xparx commented 3 years ago

Addendum:

So by doing this analysis it turns out that I had some leftover code from an earlier package changing the interpreter args. Seems like commenting those out fixes this issue. Thanks for your help!

For the record

Sorry for taking so long to get back to this.

My current configuration looks like this:

(when (or (el-get-package-exists-p "elpy") (require 'elpy nil 'noerror))
  (elpy-enable)
  (setq elpy-rpc-python-command "python3")
  (el-get-envpath-prepend "PYTHONPATH" default-directory)
  (setq python-shell-prompt-detect-failure-warning nil)
  (setq elpy-rpc-virtualenv-path 'current)
  )

Then if I manually check what my interpreter is

python-shell-interpreter
"python"
python-shell-interpreter-args
"--no-confirm-exit --no-banner --simple-prompt -i" 

When running the command you suggest It fails due to my interpreter args

unknown option --no-confirm-exit
usage: .virtualenvs/u2004/bin/python [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.

Process Python exited abnormally with code 2
Xparx commented 2 years ago

This issue seems to be related to the interpreter arguments. So far removing all but -i seems to do the trick.