Comment 2 for bug 1374741

Doug.
Yes and no. This I have spent quite some time on however in the end it appears to be erroneous but at a level too low for me to determine.
This is gentoo. I have just made a new extra gentoo system and the phenomenon repeated in s similar style. However, another gentoo dev who has an interest in this packages has it pass fine in py2.7, with the same minor version, which is enough to proclaim "something funny in your system" only I have no clue what that could be. Gentoo has fairly strict controls to ensure uniformity in system states so the inability for him to replicate while I get it in TWO systems us both quite miffed.
Can you use tox to run the tests?

Yes but I won't. Now here's the 'thing' tox is nice but it's not the panacea developers like to make it out to be. Testing in tox is testing in a virtualenv. In a gentoo ebuild, gentoo's own policies and processes render tox totally toxic 'cause it does what tox does, namely d'load everything all over again from the net and then run an ACTUAL test run cmd.

So; gentoo process says NO d'loading beyond fetching the source. Then tox comes along and d'loads everything for each python impl. NO GO. What we're left with then is within an ebuild, a test phase need run the test suite against the deps and all in the installed gentoo system, which when you think about it is actually a pretty valid exercise.

In an ebuild what I do is take the cmds to run the testsuite from the tox.ini and use those. The use of tox is by it's nature banned. However all this is just to edify you about gentoo style. What I need is a cross tester to see if there's any replication prospects in these findings. Even then your hard coded use of tox puts us at odds. This is looking to be some (invisible) oddity in my system(s) and the tests are likely fine. My py2.7 passes other testsuites fine so really don't know what gives here.