Edgewall Software
Modify

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#8061 closed defect (fixed)

0.11.3 ticket query error: NameError: global name 'set' is not defined

Reported by: dgaulke@… Owned by: Christian Boos
Priority: high Milestone: 0.11.4
Component: ticket system Version: 0.11.3
Severity: major Keywords: python23
Cc: Branch:
Release Notes:
API Changes:

Description (last modified by Christian Boos)

The python 2.3 incompatibility is back with 0.11.3. I get the following in the logs when going to "Custom Query". I wish I could upgrade python, but still not an option for me.

  File "/usr/lib/python2.3/site-packages/Trac-0.11.3-py2.3.egg/trac/ticket/query.py", line 577, in template_data
    wikify = set([f['name'] for f in self.fields
NameError: global name 'set' is not defined

Attachments (1)

8061-python-2.3-fixes-r7903.patch (2.6 KB ) - added by Remy Blank 11 years ago.
First batch of Python 2.3 compatibility fixes

Download all attachments as: .zip

Change History (18)

comment:1 by Christian Boos, 11 years ago

Keywords: python23 added
Milestone: 0.11.3
Priority: normalhigh

Hm, too bad, r7893 was not complete ;-)

comment:2 by Christian Boos, 11 years ago

Description: modified (diff)

One of the problem is that none of the Trac developers seem to be using 2.3 anymore.

Jonas, you mentioned on IRC that you couldn't run a buildbot for 2.3 as it doesn't support virtualenv. I'm not familiar with buildbot, so I don't know if the requirement for virtualenv comes from buildbot usage or if you just used virtualenv to setup the test environments for 2.4, 2.5 and 2.6. If it's the latter, then I think you could nevertheless have a test environment for Python 2.3 without virtualenv, as we have to test Trac 0.11-stable only with that version.

comment:3 by Christian Boos, 11 years ago

dgaulke: the problem you had should be fixed in r7903.

Can you please verify that it works now? Can you check for other possible Python 2.3 issues? If there are any, we need to know before releasing 0.11.3.1.

in reply to:  3 comment:4 by dgaulke@…, 11 years ago

Replying to cboos: I have installed r7903 and it fixes the custom query problem. I have tried everything else I can think of and have not found any other Python 2.3 issues. Thanks for the help on this issue.

comment:5 by Remy Blank, 11 years ago

Oh. So I broke 2.3. Again. Shesh…

Note to self: be much more careful when backporting stuff from trunk to 0.11-stable.

I agree with Christian, we need to improve our 2.3 testing. But I understand that not being able to use virtualenv is a major drawback. I'll try to set up a 2.3 environment on my new Mac mini, as it seems to be quite easy to install various Python versions using Macports (this is my first Mac, so it might take a little while). Maybe I can even set it up to build automatically for Trac's Bitten, but I'll have to catch up on reading the docs.

by Remy Blank, 11 years ago

First batch of Python 2.3 compatibility fixes

comment:6 by Remy Blank, 11 years ago

I have managed to set up a 2.3 development environment, and there are a few other issues with 2.3 compatibility. The patch above addresses a few test errors, where the incompatible code is in the test suite. However:

  • I still have two failing test cases, due to unicode objects not having a decode() method in 2.3. This might become tricky, because the missing method cannot be monkey-patched into unicode. OTOH, I'm not sure how likely we are to call decode() on a unicode object, maybe this is restricted to the test suite as well. Here's the traceback:
    ======================================================================
    ERROR: test_mixed_changeset (trac.versioncontrol.tests.svn_fs.NonSelfContainedScopedTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/joe/src/trac/0.11-stable-2.3/trac/versioncontrol/tests/svn_fs.py", line 711, in setUp
        logger_factory('test'))
      File "/home/joe/src/trac/0.11-stable-2.3/trac/versioncontrol/svn_fs.py", line 431, in __init__
        self.scope = path_utf8[len(root_path_utf8):].decode('utf-8')
    AttributeError: 'unicode' object has no attribute 'decode'
    
    ======================================================================
    ERROR: test_mixed_changeset_with_edit (trac.versioncontrol.tests.svn_fs.AnotherNonSelfContainedScopedTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/joe/src/trac/0.11-stable-2.3/trac/versioncontrol/tests/svn_fs.py", line 729, in setUp
        logger_factory('test'))
      File "/home/joe/src/trac/0.11-stable-2.3/trac/versioncontrol/svn_fs.py", line 431, in __init__
        self.scope = path_utf8[len(root_path_utf8):].decode('utf-8')
    AttributeError: 'unicode' object has no attribute 'decode'
    
    ----------------------------------------------------------------------
    Ran 719 tests in 24.709s
    
    FAILED (errors=2)
    
  • The functional tests are currently disabled, due to subprocess missing in 2.3. I'll see if I can swap in popen() to get the functional tests to run.

IMO, we are getting pretty close to the point where we won't be able to support 2.3 anymore. Even installing Python 2.3 was a pain: I had to backport a fix from 2.4 to allow it to compile with a recent readline.

Do we really want to continue supporting 2.3 for the remaining of the 0.11 series?

in reply to:  6 ; comment:7 by Christian Boos, 11 years ago

Replying to rblank:

I still have two failing test cases, due to unicode objects not having a decode() method in 2.3.

That's actually "good", as calling decode on an unicode object can be considered a bug.

Here:

self.scope = path_utf8[len(root_path_utf8):].decode('utf-8')

AttributeError: 'unicode' object has no attribute 'decode'

it's clearly a bug, as path_utf8 should be an utf-8 encoded str object.

I guess I really have to install 2.3 again as well. Anyway on Windows it's useful for building packages installers (bdist_wininst) which don't have extra runtime dependencies.

Do we really want to continue supporting 2.3 for the remaining of the 0.11 series?

Yes, I think so.

in reply to:  5 comment:8 by Christian Boos, 11 years ago

Replying to rblank:

But I understand that not being able to use virtualenv is a major drawback.

How so, as Python 2.3 should be dedicated to testing one Trac branch and one set of support packages?

in reply to:  7 ; comment:9 by Christian Boos, 11 years ago

I guess I really have to install 2.3 again as well.

Ok, so I did (2.3.5 for win32) and the first problem I had was that I hit a unittest incompatibility:

  • trac/test.py

    diff --git a/trac/test.py b/trac/test.py
    a b  
    127127        self.tearDown()
    128128        return result
    129129
     130    def __call__(self, result=None): # Python 2.3 compatibility
     131        return self.run(result)
    130132
    131133class TestCaseSetup(unittest.TestCase):
    132134    def setFixture(self, fixture):

Without that change, the SubversionRepositoryTestSetup.setup method is never called. So I'm a bit surprised it worked for you.

Then, once this is fixed, I get into further trouble with repos.svn_repos_create failing in the tests but not at the command line, followed by a problem with repos.svn_repos_load_fs2 failing at the command line as well… Well, I don't want to go down that dead-end more than that, so I'll stop there.

Anyway, the path_utf8 bug should be fixed in r7903.

comment:10 by Christian Boos, 11 years ago

(r7904 actually)

in reply to:  9 comment:11 by Christian Boos, 11 years ago

Replying to cboos:

… So I'm a bit surprised it worked for you.

Oops, I successfully managed to miss your patch until now :-) Sorry!

in reply to:  7 ; comment:12 by Remy Blank, 11 years ago

Replying to cboos:

That's actually "good", as calling decode on an unicode object can be considered a bug.

I thought it was a "no operation", but looking at the Python code, it doesn't seem to be. I wonder what it does…

But I understand that not being able to use virtualenv is a major drawback.

How so, as Python 2.3 should be dedicated to testing one Trac branch and one set of support packages?

Well, having gone through this yesterday evening, one of the annoying things with setuptools is that it installs "non-versioned" scripts, i.e. in addition to e.g. /usr/bin/easy_install-2.3, it also installs /usr/bin/easy_install, and therefore overwrites the one installed with my package manager. The same applies to /usr/bin/pygmentize, /usr/bin/tracd, /usr/bin/trac-admin, …

With virtualenv, all scripts are installed under {venv}/bin, and as an additional benefit, you don't need superuser permissions. None of this is blocking, but virtualenv is just so much more convenient.

Oops, I successfully managed to miss your patch until now :-) Sorry!

Heh, took me about two hours to come up with that patch, so it might as well be useful ;-)

comment:13 by kamil@…, 11 years ago

Just happened across this.

@rblank: You mentioned the tests don't run because subprocess isn't included in 2.3. You can drop in a copy of the subprocess module from a later Python version and it should work. It's pure python and supposed to be backwards compatible down to version 2.2

in reply to:  13 comment:14 by Remy Blank, 11 years ago

Replying to kamil@…:

You can drop in a copy of the subprocess module from a later Python version and it should work. It's pure python and supposed to be backwards compatible down to version 2.2

Right, I remember having read that when 2.4 came out. That will save me quite some work. Thanks for the reminder!

Let's see…

Ran 813 tests in 279.681s

OK

All right!

in reply to:  12 comment:15 by Christian Boos, 11 years ago

Replying to rblank:

Replying to cboos:

That's actually "good", as calling decode on an unicode object can be considered a bug.

I thought it was a "no operation", but looking at the Python code, it doesn't seem to be. I wonder what it does…

unicode.decode(encoding) does unicode.encode(sys.getdefaultencoding()).decode(encoding) … which breaks as soon as you have non-ascii characters in your unicode string, since the getdefaultencoding() is usually 'ascii'. Because of that, this call to decode will then fail with an UnicodeEncodeError

But I understand that not being able to use virtualenv is a major drawback.

How so, as Python 2.3 should be dedicated to testing one Trac branch and one set of support packages?

Well, having gone through this yesterday evening, one of the annoying things with setuptools is that it installs "non-versioned" scripts, i.e. in addition to e.g. /usr/bin/easy_install-2.3, it also installs /usr/bin/easy_install, and therefore overwrites the one installed with my package manager. The same applies to /usr/bin/pygmentize, /usr/bin/tracd, /usr/bin/trac-admin, …

But that's only true if you have installed Python 2.3 itself at that location (/usr), and if you did that, then you probably also overwrote your previous default /usr/bin/python…

If instead you build and install Python with a configuration parameter of e.g. --prefix=/opt/python-2.3.5, then easy_install will install everything below /opt/python-2.3.5/bin.

comment:16 by Remy Blank, 11 years ago

Milestone: 0.11.30.11.4
Resolution: fixed
Status: newclosed

Patch applied in [7908]. All tests (except those requiring php, which I don't have at hand) pass with Python 2.3.

I'll close this ticket against 0.11.4 for now. We can move it back if we do a .1 release.

comment:17 by Remy Blank, 11 years ago

Owner: set to Christian Boos

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.