[possible solution provided] I need a hint to debug this Elpy pytest failure

[sten0]

Hi @galaunay,

Thank you for your work replacing Rope with Jedi! It's exciting and much appreciated work :-) I've locally rebased the Debian package onto 4032c72, and finally learned enough about the details and pitfalls of Python packaging to make progress with adding an additional set of testing to our CI. Unfortunately, most of the Jedi tests blow up, most often with 'PosixPath' object has no attribute 'endswith'. On the upside, this is not a regression, as I've confirmed 1.35 is also affected I've attached a terrifyingly long build log filed with backtraces (elpy_1.35.0+20.g4032c72-1_amd64.build.txt) which I doubt you'll want to look at ;-)

If you could share a hint about whether you think it's a Jedi issue (eg: a Debian integration issue in Jedi), an Elpy issue (maybe Python 3.9 related?), or something that looks like it's my fault (eg: a Debian integration issue in Elpy's pytests), I'd very much appreciate it! If it's something in Elpy, then maybe something like this is the solution? https://github.com/python-poetry/poetry/pull/2582/commits

Cheers, Nicholas

[sten0]

Ah, this is the problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977931

For anyone else encountering this issue, it appears Jedi 0.17 requires Parso 0.7, and Parso 0.8 requires Jedi 0.18.

Merry Christmas!

[sten0]

Oh no... Parso 0.8 + Jedi 0.18 doesn't solve pytest failures. There are obvious actionable bugs like:

E       AssertionError: Tuples differ: (PosixPath('/tmp/elpy-teste5ye5srh/test.py'), 0) != ('/tmp/elpy-teste5ye5srh/test.py', 0)
E       
E       First differing element 0:
E       PosixPath('/tmp/elpy-teste5ye5srh/test.py')
E       '/tmp/elpy-teste5ye5srh/test.py'
E       
E       - (PosixPath('/tmp/elpy-teste5ye5srh/test.py'), 0)
E       ? ----------                                 -
E       
E       + ('/tmp/elpy-teste5ye5srh/test.py', 0)

keyword and type errors like

    def run_with_debug(jedi, name, fun_kwargs={}, *args, **kwargs):
        re_raise = kwargs.pop('re_raise', ())
        try:
>           script = jedi.Script(*args, **kwargs)
E           TypeError: __init__() got an unexpected keyword argument 'source'

elpy/jedibackend.py:680: TypeError

out of bounds errors like

        offset = nth_newline_offset + col
        if offset > len(text):
>           raise ValueError("Line {0} column {1} is not within the text"
                             .format(line, col))
E           ValueError: Line 1 column 4 is not within the text

elpy/jedibackend.py:672: ValueError

what looks like a Debian integration error (my my responsibility to discover the correct workaround)

>               with open(name.module_path) as f:
E               FileNotFoundError: [Errno 2] No such file or directory: '/tmp/elpy-test0pxt4893/project.py'

elpy/jedibackend.py:524: FileNotFoundError

and this one, which makes me wonder if the disabled virtualenv case is not yet supported

_____________ TestRPCGetNames.test_shouldreturn_names_in_same_file _____________

self = <elpy.tests.test_jedibackend.TestRPCGetNames testMethod=test_shouldreturn_names_in_same_file>

    def test_shouldreturn_names_in_same_file(self):
        filename = self.project_file("test.py", "")
        source, offset = source_and_offset(
            "def foo(x, y):\n"
            "    return x + y\n"
            "c = _|_foo(5, 2)\n")
    
>       names = self.backend.rpc_get_names(filename,
                                           source,
                                           offset)

elpy/tests/support.py:1027: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
elpy/jedibackend.py:526: in rpc_get_names
    offset = linecol_to_pos(text, name.line, name.column)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

@galaunay, would you please comment on that last point?

Given all the changes between Jedi 0.17 and 0.18, I suspect it would be the best use of time to drop support for all Jedi of versions < 0.18, and also because 0.17 probably doesn't support the new refactoring features very well, and because most users are using an rpc-virtualenv making this low-cost to them.

Full log available here: elpy_1.35.0+20.g4032c72-1_amd64-2020-12-27T20:12:55Z.build.txt