{{{
test_changing_password (apps.users.tests.test_admin.UserAdminLiveServer)
failed:
NoSuchElementException()
Unfortunately, tracebacks cannot be pickled, making it impossible for the
parallel test runner to handle this exception cleanly.
In order to see the traceback, you should install tblib:
pip install tblib
(...)
subsuite_index, events = test_results.next(timeout=0.1)
File "/usr/lib/python2.7/multiprocessing/pool.py", line 659, in next
raise value
TypeError: can't pickle traceback objects
}}}
After installing tblib everything is ok:
{{{
(...)
----------------------------------------------------------------------
Ran 121 tests in 53.847s
FAILED (errors=2, skipped=2)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25497>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Old description:
> The error occurs when `NoSuchElementException` (selenium) exception is
> raised:
>
> {{{
>
> test_changing_password (apps.users.tests.test_admin.UserAdminLiveServer)
> failed:
>
> NoSuchElementException()
>
> Unfortunately, tracebacks cannot be pickled, making it impossible for the
> parallel test runner to handle this exception cleanly.
>
> In order to see the traceback, you should install tblib:
>
> pip install tblib
>
> (...)
>
> subsuite_index, events = test_results.next(timeout=0.1)
> File "/usr/lib/python2.7/multiprocessing/pool.py", line 659, in next
> raise value
> TypeError: can't pickle traceback objects
> }}}
>
> After installing tblib everything is ok:
>
> {{{
> (...)
>
> ----------------------------------------------------------------------
> Ran 121 tests in 53.847s
>
> FAILED (errors=2, skipped=2)
> }}}
New description:
The error occurs when `NoSuchElementException` (selenium) exception is
raised:
{{{
test_changing_password (apps.users.tests.test_admin.UserAdminLiveServer)
failed:
NoSuchElementException()
Unfortunately, tracebacks cannot be pickled, making it impossible for the
parallel test runner to handle this exception cleanly.
In order to see the traceback, you should install tblib:
pip install tblib
(...)
subsuite_index, events = test_results.next(timeout=0.1)
File "/usr/lib/python2.7/multiprocessing/pool.py", line 659, in next
raise value
TypeError: can't pickle traceback objects
}}}
After installing `tblib` everything is ok:
{{{
(...)
----------------------------------------------------------------------
Ran 121 tests in 53.847s
FAILED (errors=2, skipped=2)
}}}
--
--
Ticket URL: <https://code.djangoproject.com/ticket/25497#comment:1>
Comment (by knbk):
`tblib` was added as a new dependency to `requirements/base.txt`. Simply
rerunning `pip install -r tests/requirements/py3.txt` (or `py2.txt`)
solves any issues. Should the upgrade process be documented?
--
Ticket URL: <https://code.djangoproject.com/ticket/25497#comment:2>
Comment (by user0007):
Replying to [comment:2 knbk]:
> `tblib` was added as a new dependency to `requirements/base.txt`. Simply
rerunning `pip install -r tests/requirements/py3.txt` (or `py2.txt`)
solves any issues. Should the upgrade process be documented?
But it fails running custom tests, not django tests. Should I add `tblib`
to my all projects requirements.txt?
--
Ticket URL: <https://code.djangoproject.com/ticket/25497#comment:3>
* severity: Normal => Release blocker
* stage: Unreviewed => Accepted
Comment:
Requiring tblib is fine for Django itself, but clearly not for all user
projects.
--
Ticket URL: <https://code.djangoproject.com/ticket/25497#comment:4>
Comment (by collinanderson):
Would it make sense to just disable parallel tests if `tblib` is not
installed?
--
Ticket URL: <https://code.djangoproject.com/ticket/25497#comment:5>
* status: new => closed
* resolution: => worksforme
Comment:
This ticket's description is misleading. Parallel test *fail to report
failures correctly and suggest to install tblib* when it isn't installed.
This is the intended and documented behavior. It was discussed on the
DevelopersMailingList prior to the feature being implemeted and committed.
As shown in your description, there's a detailed explanation message. I'm
not sure what else I could do
You have three options, pick your favorite:
1) Don't run tests in parallel and get exactly the same behavior as in
Django 1.8.
2) Have your tests crash hard if an exception occurs.
3) Install `tblib`.
Claude, in case this isn't clear, `tblib` is only required for getting
correct failure reports when running tests in parallel.
Collin, I don't think it makes sense to ignore the `--parallel` option
when `tblib` isn't installed. As long as tests complete without errors or
failures, `tblib` isn't needed.
Of course as soon as you have a test failure you'll want to know why it
fails. If you're absolutely unable to `pip install tblib` and absolutely
need to run tests in parallel — I can't see why that would be the case,
but for the sake of the argument let's assume at least one user will be in
this situation — you can re-run just the failing test without the
`--parallel` option.
If someone proposes a patch to improve the situation, we can reopen this
discussion.
--
Ticket URL: <https://code.djangoproject.com/ticket/25497#comment:6>