pytest explodes if getcwd fails #1235
Comments
|
agred, that's not robust behaviour. Also it's wrong for traceback representation to use It's probably also possible to fix this in the pytest-2.8 series maybe by e.g. changing to "startdir" before we call the |
|
Full disclosure: I don't plan to work on this. I was able to find the rogue On Tue, Dec 8, 2015 at 12:54 PM holger krekel [email protected]
|
|
@bukzor no problem, thanks for reporting anyway! |
RonnyPfannschmidt
added
type: enhancement
|
Ran in to this bug recently. |
|
Seems like in every case someone should just create a subdirectory OF |
|
For example: any test function using this fixture, Oh, I'm not suggesting that py.test should do this, I'm just suggesting that OPs or commentors on this thread and #470, can take care of this for themselves with a fixture like this. |
|
I agree that it's due to incorrectly written tests, but the problem is that it's hard to figure out which test caused the issue (especially when you didn't write all of them yourself). |
|
ah, I hear you on that @MagiMaster |
|
I ran into the same issue (I needed to make sure my code does now blow up when cwd() gets The bad news is that @hangtwenty solution does not work. See my branch for the details: |
|
@dmerejkowsky I'm not saying this defensively, just trying to help if I can: I can tell you with confidence that my solution worked. Perhaps there is a subtle difference between the test you've added, and the real-world scenario I was in. Only mentioning in case this might reveal something in your test that is too different, and why it doesn't work. My example has no usage of In any case, it might be orthogonal to OP's request:
That seems to be the important thing: helping people track down where the hell the problem is coming from |
|
@hangtwenty : No problem man :) Reproducing bugs is hard ... Anyway, in my use case pytest only crashes when the tests fails, so it's not that bad.
Agreed. I may have a look at this in the future. After all, the issue is marked as "easy" :) |
|
Hum. Interesting development. When testing with Python3, the tests I've added pass. This may be because Python2 raises OSError, and Python3 FileNotFoundError. @hangtwenty : are you running your tests with Python3 ? That maybe one of the "subtle differences" we are looking for ... |
|
@dmerejkowsky That's very interesting. I was using Python 2.7.9 actually. The main difference I was noticing was that your example is using |
|
I also encountered this bug during the the test phase of conda build (http:https://conda.pydata.org/docs/building/recipe.html) If you need further information I'll be happy to provide it. |
|
INTERNALERROR> File "/home/marscher/anaconda/lib/python2.7/site-packages/_pytest/_code/code.py", line 571, in _makepath The argument to path in _makepath is a file, this does not make any sense, right? |
|
The argument is always the name of the python file under test. |
I think that's OK, it should be able to guess a relative path from either a file path or directory path. I found a trivial fix for the problem: +++ b/_pytest/main.py
@@ -403,7 +403,7 @@ class Node(object):
else:
style = "long"
- return excinfo.getrepr(funcargs=True,
+ return excinfo.getrepr(funcargs=True, abspath=True,
showlocals=self.config.option.showlocals,
style=style, tbfilter=tbfilter)Of course now all paths in tracebacks are full paths instead of relative to the current directory, but I personally don't think that's a problem. In fact I know Eclipse does some internal workarounds in order to make the links in pytest's traceback clickable in its IDE because they are relative instead of absolute. I didn't work on this before because my main environment is Windows, and I can't reproduce the bug on it. 😑 |
* extra_template_vars plugin hook Closes #541 * Workaround for cwd bug Based on pytest-dev/pytest#1235 (comment)
* extra_template_vars plugin hook Closes #541 * Workaround for cwd bug Based on pytest-dev/pytest#1235 (comment)
* extra_template_vars plugin hook Closes #541 * Workaround for cwd bug Based on pytest-dev/pytest#1235 (comment)
Demonstration below.
While in my toy example it's quite clear what the issue is, the fact that it doesn't show the original error, or even have the erroneous code anywhere on the stack means that it's extremely hard to find the source of this issue in a real project.
The text was updated successfully, but these errors were encountered: