maximum recursion depth exceeded

[alexeyt820]

Thanks for submitting an issue!

Here's a quick checklist in what to include:

• pytest (3.1.2) seems enters into infinite recursion, which causes RuntimeError: maximum recursion depth exceeded. 3.1.1 works fine with same code. Traceback is attached
• pip list
  backports.ssl-match-hostname (3.4.0.2)
  certifi (2017.4.17)
  chardet (3.0.3)
  coverage (4.4.1)
  EasyProcess (0.2.3)
  elasticsearch (5.4.0)
  email (6.0.0a1)
  idna (2.5)
  iniparse (0.4)
  iso8601 (0.1.11)
  kitchen (1.1.1)
  nose (1.3.7)
  nose-exclude (0.5.0)
  pip (9.0.1)
  psycopg2 (2.7.1)
  py (1.4.34)
  pycurl (7.19.0)
  pygpgme (0.3)
  pyliblzma (0.5.3)
  pyodbc (4.0.16)
  pytest (3.1.2)
  pytest-cov (2.5.1)
  PyVirtualDisplay (0.2.1)
  pyxattr (0.5.1)
  PyYAML (3.12)
  requests (2.17.3)
  setuptools (0.9.8)
  urlgrabber (3.10)
  urllib3 (1.21.1)
  yum-metadata-parser (1.1.4)
• pytest 3.1.2. CentOS 7
  traceback.txt

[nicoddemus]

@alexeyt820 thanks for the report.

The traceback seems related to #2140:

...
  File "/devops_bulk_upgrade/scripts/my_hotfix/lib/py/_path/common.py", line 402, in __call__
    return py.std.fnmatch.fnmatch(name, pattern)
  File "/devops_bulk_upgrade/scripts/my_hotfix/lib/py/_apipkg.py", line 125, in __makeattr
    result = importobj(modpath, attrname)
  File "/devops_bulk_upgrade/scripts/my_hotfix/lib/py/_apipkg.py", line 48, in importobj
    module = __import__(modpath, None, None, ['__doc__'])
  File "/usr/lib/python2.7/site-packages/_pytest/assertion/rewrite.py", line 97, in find_module
    if not self._should_rewrite(name, fn_pypath, state):
  File "/usr/lib/python2.7/site-packages/_pytest/assertion/rewrite.py", line 169, in _should_rewrite
    if fn_pypath.fnmatch(pat):
  File "/devops_bulk_upgrade/scripts/my_hotfix/lib/py/_path/common.py", line 209, in fnmatch
    return FNMatcher(pattern)(self)
  File "/devops_bulk_upgrade/scripts/my_hotfix/lib/py/_path/common.py", line 397, in __call__
    name = path.basename
  File "/devops_bulk_upgrade/scripts/my_hotfix/lib/py/_path/common.py", line 97, in basename
    return self._getbyspec('basename')[0]
RuntimeError: maximum recursion depth exceeded

This should be fixed by py>=1.4.33. I see in your pip freeze that you are using 1.4.34, so this should not be a problem. On the other hand the traceback has this path on it: /devops_bulk_upgrade/scripts/my_hotfix/lib/py/_path/common.py which suggests the py version being imported is not the one listed by pip freeze. Can you please make sure the code is using the correct py version?

[nicoddemus]

Hmm looking further into it, your traceback shows:

  File "/devops_bulk_upgrade/scripts/my_hotfix/lib/py/_path/common.py", line 209, in fnmatch
    return FNMatcher(pattern)(self)

But looking at the same line in py 1.4.34 it is clear that the code in question is using a different py version... in fact, it seems to be version 1.4.31.

[The-Compiler]

Maybe we should add a check for py's version to pytest and bail out with a better error if an older py gets loaded?

[RonnyPfannschmidt]

we can hardly fix broken installations - py was being overridden by another location there, and pkg_ressources reported the first version which was correct

im inclined to close this one as "problem exists between admin of user and user"

[The-Compiler]

@RonnyPfannschmidt We can check py.__version__ and show a human-readable error.

[RonnyPfannschmidt]

ah right, i missed we didnt update it to setuptools_scm yet

[nicoddemus]

TBH I'm divided here:

We already do pin the correct version in setup.py, not sure we should also do an additional check in the source; after all, should we do that for all dependencies as well? (of course pytest only depends on colorama and py for now, but nonetheless). It is a small maintenance quirk because we also have to remember to update the check when we update the pin in setup.py.

On the other hand that's the second report we had about this (the other being #2485 ), so it might make sense to do this if more and more users might encounter this error.

After writing all this I think this might be the case of practicability beats purity, so adding a check might be the better option (we are talking about a few lines of code anyway).

What you guys think?

[nicoddemus]

Closing for now, it seems this should no longer be a problem.