The use of __file__ causes the tests to fail in Python 3.4

Bug #1269898 reported by Barry Warsaw on 2014-01-16
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
oneconf (Ubuntu)
High
Barry Warsaw
Trusty
High
Barry Warsaw

Bug Description

In order to properly build against both Python 3.3 and 3.4, the package needs to B-D on python3-all. I'll provide a merge proposal momentarily.

Related branches

Actually, the problem is a little deeper. I see two test failures with Python 3.4 against trunk code. Still investigating, by you should be able to reproduce with this in Trusty (assuming python3.4 is installed).

$ python3.4 setup.py nosetests -vv --test test.test_syncing

======================================================================
FAIL: Test when getting all machines errors, we should stop syncing
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/barry/projects/ubuntu/oneconf/lp1269898/test/test_syncing.py", line 417, in test_get_all_machines_error
    self.assertFalse(self.check_msg_in_output("Saving updated", check_errors=False))
nose.proxy.AssertionError: AssertionError: True is not false

======================================================================
FAIL: Test server not responsing at all
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/barry/projects/ubuntu/oneconf/lp1269898/test/test_syncing.py", line 391, in test_server_error
    self.assertFalse(self.check_msg_in_output("Saving updated", check_errors=False))
nose.proxy.AssertionError: AssertionError: True is not false

summary: - Build-Depend on python3-all
+ Python 3.4 failures
Daniel T Chen (crimsun) wrote :

Seems to be deeper than these errors, even. While resolving the build failures in a pristine sbuild using the python3-all addition, I'm seeing timeout failures. If I then add python2.7-all to the b-d, then I receive many test failures due to test/test_mainfeatures.py (line 69), since /tmp/oneconf-test/cache/0000 exists.

Changed in oneconf (Ubuntu):
status: New → Confirmed
Matthias Klose (doko) on 2014-02-23
tags: added: ftbfs python3.4
Changed in oneconf (Ubuntu):
importance: Undecided → High
milestone: none → ubuntu-14.02
Barry Warsaw (barry) on 2014-03-17
Changed in oneconf (Ubuntu Trusty):
assignee: nobody → Barry Warsaw (barry)
Barry Warsaw (barry) wrote :

Okay, at least one test is caused by some bogus use of __file__. Python 3.3 and 3.4 treat __file__ differently in that with 3.3, the path may be relative to cwd, but in 3.4 it is absolute. oneconf uses the *path* of the logo file as its sha224 checksum (not its contents!) so that breaks the logo checksum test.

paths.py really probably should at least be using the absolute path in all cases, but I don't know if this will break its functionality. Ultimately it should not be using __file__ anyway, since that is not a reliable API. Instead it should be using pkg_resource.get_resource_filename() which comes from the setuptools package.

Barry Warsaw (barry) wrote :

Well, at least abspath()ing FAKE_WALLPAPER makes Python 3.3 break in the same way, so that's a good thing. :)

Barry Warsaw (barry) on 2014-03-17
summary: - Python 3.4 failures
+ The use of __file__ causes the tests to fail in Python 3.4
Changed in oneconf (Ubuntu Trusty):
status: Confirmed → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package oneconf - 0.3.6

---------------
oneconf (0.3.6) trusty; urgency=medium

  * d/control: Build-Depend on python3-all.
  * paths.py: Ensure a predictable FAKE_WALLPAPER path in all supported
    Python versions, since __file__ is absolute in Python 3.4 and relative
    in all older Pythons. (LP: #1269898)
 -- Barry Warsaw <email address hidden> Thu, 16 Jan 2014 13:25:41 -0500

Changed in oneconf (Ubuntu Trusty):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers