apheleia
apheleia copied to clipboard
Error when calling both isort and black over TRAMP
I'm testing with this Python file, both locally and on a server over TRAMP:
import struct
import binascii
a = 'single quotes'
My config looks like this:
(use-package apheleia
:ensure t
:config
(setq apheleia-remote-algorithm 'remote))
Both locally and remotely, everything works fine and the code is formatted with black
to be this:
import struct
import binascii
a = "single quotes"
Now I also want to run isort
before black
, so I update my configuration to this:
(use-package apheleia
:ensure t
:config
(setf (alist-get 'isort apheleia-formatters)
'("isort" "--stdout" "-"))
(setf (alist-get 'python-mode apheleia-mode-alist)
'(isort black))
(setq apheleia-remote-algorithm 'remote))
Locally, everything still works fine, and now we can see that both tools made modifications:
import binascii
import struct
a = "single quotes"
However, remotely I now see this error in the log:
$ black -
error: cannot format -: '\x1b'
Oh no! 💥 💔 💥
1 file failed to reformat.
Command failed with exit code 123.
One workaround to this is to change apheleia-remote-algorithm
from 'remote
to 'local
, in which case everything is formatted as expected. However, I don't want to do this because with 'local
the black
configuration in the remote pyproject.toml
is not respected (I don't know if that's intended or another bug).
Any idea what this issue is? Is there any way to get more verbose error messages or logs about what's happening?
We had this problem in https://github.com/radian-software/apheleia/pull/76 and I think it was solved by (in combination with other things) switching from ssh
to sshx
as the TRAMP mode. Which one are you using?
I think for local
there is no way for pyproject.toml
to be respected, since the formatter is being run on your local machine which does not have pyproject.toml
on it.
I was using ssh:
, but I just tried it with sshx:
and have the same error. Any other suggestions to debug this?
Unfortunately no, we struggled a lot with this the last time it came up. You (or someone) would probably have to dive a bit deeper into the source of TRAMP to figure out how the command is being run, or potentially looking at Black/Isort to see if there is any code in them that could be generating this sort of output. I suspect it won't be an easy investigation - I wasn't able to get to the bottom of it in the linked PR either.