unsaved editor files cause cryptic crash #238
Comments
|
I was able to reproduce this error in my stestr repo like following. It looks there's a bug in handling non-existent files. |
|
And, it looks this issue comes from unittest2.loader. So, I'm not sure it's good to fix it in stestr. Maybe, we should fix it in unittest2? |
|
Hmm I'm curious if this bug also happens with unittest (not unittest2) too? Both are supposed to have a default discovery pattern of If it is an issue with unittest2 we might have a hard time getting a fix merged that code base hasn't been touched in ages and was just a backport of newer stdlib unittest features. |
|
hmm, it doesn't happen with unittest but happens with unittests. |
|
Can we try to import |
|
Yeah, we'll have to raise this in testtools as a bug. Honestly I really think testtools should drop the unittest2 usage now. It's not really needed anymore since unittest2 doesn't backport anything of note to supported python versions anymore. It introduces more bugs at this point than it solves. |
Currently testtools bases all of it's unittest extensions off of unittest2 instead of the stdlib unittest. At one point this made sense since unittest2 provided a stable base as unittest in stdlib added features. But it's been ~5 years since there was a unittest2 release (or a patch merged) and things have changed since then. The best example of this is of the supported python versions listed in the unittest2 project description/README only one is still supported by upstream python, 2.7, which goes end of life at the end of this year. More specific to testtools the use of unittest2 causes a whole slew of issues because of differences in behavior with stdlib unittest. For example here a couple issues encountered: https://bugs.launchpad.net/testtools/+bug/1467558 https://bugs.launchpad.net/testtools/+bug/1417803 mtreinish/stestr#238 testing-cabal#272 which are caused, at least in part, by unittest2. There are likely other bugs related to it that haven't been reported (or I just missed/forgot about). At this point it's better to remove the unittest2 usage and just rely on the upstream stdlib unittest which if nothing else is actively maintained. It'll improve compatibility using the testtools runner with stdlib unittest test suites and removes the class of bugs caused by the differences in unittest2. Fixes testing-cabal#263
|
I pushed up testing-cabal/testtools#277 we'll see how it goes... |
|
Oh, thanks! |
|
@masayukig @aspiers can you test stestr 2.5.0 to see if this still exists? We switched the internal test runner to use stdlib unittest directly (instead of testtools.run) in: #256 which I think should address this. |
|
Upgrading to 2.5.0 does indeed seem to have fixed it! Many thanks :-) |
|
Ok great, I thought it would. Abandoning testtools/unittest2 in the test execution path fixed a whole class of problems, unittest2 just doesn't work well with modern python 3. I'll go ahead and close this issue now. |
Issue description
Steps to reproduce the problem
Edit an existing testcase file in emacs without saving it. emacs creates a lock symlink which is presumably the cause of the issue:
Expected behavior
stestr runs as normal.
Actual behavior
stestr crashes with a hopelessly cryptic error.
System information
stestr version (
stestr --version): 2.2.0Python release (
python --version): 3.6.5pip packages (
pip freeze):The text was updated successfully, but these errors were encountered: