setup.py test failing

[Martin Schulze <spam.martin.schulze@…>]

Doing the following steps result in failed tests for bitten on my machine:

$ cd /tmp/
$ svn checkout http://svn.edgewall.org/repos/bitten/trunk bitten
...
Checked out external at revision 37.

Checked out revision 1027.
$ cd bitten
$ python2 setup.py test
...
Ran 290 tests in 3.985s

FAILED (failures=5, errors=157)

Most of the errors are like this one:

ERROR: test_process_config_changes (bitten.tests.admin.BuildMasterAdminPageProviderTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/bitten/bitten/tests/admin.py", line 43, in setUp
    cursor.execute(stmt)
  File "/usr/lib/python2.7/site-packages/trac/db/util.py", line 56, in execute
    r = self.cursor.execute(sql)
  File "/usr/lib/python2.7/site-packages/trac/db/sqlite_backend.py", line 78, in execute
    result = PyFormatCursor.execute(self, *args)
  File "/usr/lib/python2.7/site-packages/trac/db/sqlite_backend.py", line 56, in execute
    args or [])
  File "/usr/lib/python2.7/site-packages/trac/db/sqlite_backend.py", line 48, in _rollback_on_error
    return function(self, *args, **kwargs)
OperationalError: table bitten_config already exists

The installed Trac version is 1.0.1

Did I miss something? I believe I had the same problem some time ago but I can't remember if and how I solved it.

[Martin Schulze <spam.martin.schulze@…>]

Log of the failing testrun

[Martin Schulze <spam.martin.schulze@…>]

After some more investigation I found out that this is a python2/3 issue.

On my system the python command maps to python3 but the code expects to get Python 2.

The tests are run with the python2 command (as you can see in the description) but some tests invoke python on command line for example Command Line Test Case?.test_multiple_arguments says:

cmdline = CommandLine('python', [script_file, 'foo', 'bar', 'baz'])

To me it seems the code is rather oblivious to this problem. I can think of following solutions:

Better Communication

Communicate more clearly the deeper problems on systems where python does not mean Python 2. This should also entail an explanation on how to solve this. (I used virtualenv but I am not sure if this can be used "concurrently" with applications that assume python to mean python3)

Apart from the documentation this would require very little work on the developer side but much more attention an frustration on the user side.

Parametrizable Interpreter path

All instances of using python on the command-line should use a variable that can be set by the user at startup.

This still requires some attention by the user but offers a much more localized solution. However, it would amount to some tedious work to "clean" the code from hardcoded python invocations and to retain it in this state. (Each patch would have to be checked!)

Autodetection

I don't know how easy this would be to implement but the code that invokes the command-line has already been called with the correct interpreter. Maybe it is possible to get the path to that interpreter and use it for the invocations on the command line.