#8061 closed defect (fixed)
0.11.3 ticket query error: NameError: global name 'set' is not defined
Reported by: | 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: | |||
Internal Changes: |
Description (last modified by )
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)
Change History (18)
comment:1 by , 16 years ago
Keywords: | python23 added |
---|---|
Milestone: | → 0.11.3 |
Priority: | normal → high |
comment:2 by , 16 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.
follow-up: 4 comment:3 by , 16 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.
comment:4 by , 16 years ago
follow-up: 8 comment:5 by , 16 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 , 16 years ago
Attachment: | 8061-python-2.3-fixes-r7903.patch added |
---|
First batch of Python 2.3 compatibility fixes
follow-up: 7 comment:6 by , 16 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 adecode()
method in 2.3. This might become tricky, because the missing method cannot be monkey-patched intounicode
. OTOH, I'm not sure how likely we are to calldecode()
on aunicode
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 inpopen()
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?
follow-ups: 9 12 comment:7 by , 16 years ago
Replying to rblank:
I still have two failing test cases, due to
unicode
objects not having adecode()
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.
comment:8 by , 16 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?
follow-up: 11 comment:9 by , 16 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 127 127 self.tearDown() 128 128 return result 129 129 130 def __call__(self, result=None): # Python 2.3 compatibility 131 return self.run(result) 130 132 131 133 class TestCaseSetup(unittest.TestCase): 132 134 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:11 by , 16 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!
follow-up: 15 comment:12 by , 16 years ago
Replying to cboos:
That's actually "good", as calling
decode
on anunicode
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 ;-)
follow-up: 14 comment:13 by , 16 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
comment:14 by , 16 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!
comment:15 by , 16 years ago
Replying to rblank:
Replying to cboos:
That's actually "good", as calling
decode
on anunicode
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 , 16 years ago
Milestone: | 0.11.3 → 0.11.4 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
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 , 16 years ago
Owner: | set to |
---|
Hm, too bad, r7893 was not complete ;-)