Closed Mekk closed 3 years ago
I patched anaconda slightly to give more detail about what was called (simply by extending error message to note which called function crashed) and here it is:
service_factory.exceptions.ServiceException: (500, '{"jsonrpc": "2.0", "id": 1, "error": {"code": -32000, "message": "Server error: Calling <function eldoc at 0x7f7c79d31160> with named args: source=..., line=17, column=11, path=\'/home/marcink/GAUSS/python/sfx__repository/sample/repo/basic_log.py\'", "data": "TypeError(\'__init__() takes from 1 to 2 positional arguments but 5 positional arguments (and 1 keyword-only argument) were given\')"}}')
I am not 100% sure, but it seems to me that aforementioned line 99 is related to python code snippet defined inside anaconda-mode-server-command
. If so, it is triggered by:
result = f(jedi.Script(source, line, column, path, environment=virtual_environment))
what also matches error message
Doom emacs uses anaconda 0.1.13 and jedi 0.18.0. Jedi sources have the following there:
def __init__(self, code=None, *, path=None, environment=None, project=None):
so looks like giving positional args is not supported here.
I resolved this by changing to
result = f(jedi.Script(source, path=path, environment=virtual_environment))
but then next error appears:
Traceback (most recent call last):
File "/home/marcink/DEV_git/emacs/doom-emacs/.local/etc/anaconda/0.1.13/service_factory-0.1.6-py3.8.egg/service_factory/service.py", line 101, in apply
result = method(**params)
File "<string>", line 100, in wrapper
File "<string>", line 156, in eldoc
AttributeError: 'Script' object has no attribute 'call_signatures'
so looks like there is some deeper incompatibility.
0.18.0 seems to be the newest and brightest version of jedi, so I bet it changed in incompatible way at some moment.
Jedi changelog mentions deprecating call_signatures in entry for 0.16.0. Looking at the repo, it seems the method was actually removed at 0.18.0 (0.17.2 has it).
So I suppose this bug is about patching anaconda to work with jedi 0.18.0.
As a side note, it seems anaconda-mode.el doesn't restrict jedi version installed: it constructs pip dependency jedi>=0.13.0
but doesn't limit upper version. Probably it would be better to limit two-side.
I reported the latter problem separately, as https://github.com/pythonic-emacs/anaconda-mode/issues/402. This issue is about making anaconda work with jedi 0.18.0
By default anaconda installs a rather old version 0.13.
0.18 is only 6 days old though and not a good choice for anaconda as it doesn't have python 2 support.
But I agree that anaconda should also work with 0.18 if that's installed. Would be great if you can help with a PR that supports both (all) jedi versions.
Unfortunately anaconda doesn't install jedi 0.13 by default. It installs newest version available on pypi at the moment (it asks for jedi>=0.13
what since Dec 25th results in 0.18). But that's #402.
PS Force-downgrading jedi to 0.17.2 seems to help (alth. I tested it very briefly). So I'd suggest starting from #402 and adding <0.18
restriction for jedi there, to resolve the immediate issue.
@Mekk Can you check if https://github.com/pythonic-emacs/anaconda-mode/pull/403 works ?
I tested it briefly and seems it is OK (jedi 0.18 was installed but now I don't see errors and eldoc hints are displayed).
@Mekk Can you check if #403 works ?
Works fine for me too, thanks!
Recently I upgraded python to 3.9 on my laptop and rebuild all environments, anaconda-mode was broken due to installed fresh version of jedi.
Thanks @dakra for his patch, it solved the problem!
For the sake of possible Doom! Emacs users, adding to packages.el
:
(package! anaconda-mode
:recipe (:host github :repo "dakra/anaconda-mode")
:pin "810163d5a65e62d58f363e2edaa3be70e6d82e25")
switches to this patched version.
I merged the PR and also created a new version tag so users of melpa-stable will get it too.
I am just trying doom emacs, and on python files I get repeatable TypeErrors while editing python files (full traceback below). After some analysis I found that disabling anaconda-eldoc-mode resolves the issue, so the problem lies there.
*anaconda-mode*
buffer contains numerous entries like:(and again, and again, and again…)