Last modified: 2014-02-24 13:28:34 UTC
On Tools Lab, my tool http://tools.wmflabs.org/russbot/csd.py is throwing the following exception (edited for brevity): /data/project/russbot/cgi-bin/csd.py in () => 37 import pywikibot /shared/pywikipedia/rewrite/pywikibot/__init__.py in () => 418 from .page import Page, ImagePage, Category, Link, User, ItemPage, PropertyPage, Claim /shared/pywikipedia/rewrite/pywikibot/page.py in () => 17 import pywikibot.site /shared/pywikipedia/rewrite/pywikibot/site.py in () => 32 from pywikibot import pagegenerators /shared/pywikipedia/rewrite/pywikibot/pagegenerators.py in () => 31 from pywikibot.comms import http /shared/pywikipedia/rewrite/pywikibot/comms/http.py in () => 62 version=pywikibot.version.getversiondict()) /shared/pywikipedia/rewrite/pywikibot/version.py in getversiondict() 51 else: => 52 (tag, rev, date, hsh) = getversion_git(_program_dir) /shared/pywikipedia/rewrite/pywikibot/version.py in getversion_git(path='/shared/pywikipedia/rewrite') 132 try: 133 subprocess.Popen([cmd], stdout=subprocess.PIPE).communicate() => 134 except WindowsError: 135 # some windows git versions provide git.cmd instead of git.exe 136 cmd = 'git.cmd' WindowsError undefined <type 'exceptions.NameError'>: global name 'WindowsError' is not defined args = ("global name 'WindowsError' is not defined",) message = "global name 'WindowsError' is not defined" Curiously, I can import pywikibot when starting Python from the command prompt; the exception is only thrown when Python is started from the webserver. local-russbot@tools-login:~$ version.py Pywikibot: [https] r-p-pywikibot-core.git (ef8fcb5, g2752, 2014/02/11, 06:31:56, ok) Release version: 2.0b1 Python: 2.7.3 (default, Sep 26 2013, 20:03:06) [GCC 4.6.3] unicode test: ok
A little further testing shows that, when starting Python from the command prompt, WindowsError is still undefined (not too surprising, since this is a Linux machine), but evidently importing pywikibot in this configuration does not hit the try/except block on line 134 of version.py
We can either replace it by OSError, or add try: WindowsError except NameError: class WindowError(OSError): pass somewhere on top (or in pywikibot.exceptions?)
I'd vote for OSError as more general. If you wanted to go the latter route, it would have to be in version.py; putting it in any other module would not work because of namespace issues.
*** Bug 61816 has been marked as a duplicate of this bug. ***
Change 114988 had a related patch set uploaded by Merlijn van Deen: (bug 61231) use OSError as WindowsError does not exist on unix hosts https://gerrit.wikimedia.org/r/114988
Change 114988 merged by jenkins-bot: (bug 61231) use OSError as WindowsError does not exist on unix hosts https://gerrit.wikimedia.org/r/114988
This just leads to a new error: /usr/lib/python2.7/subprocess.py in _execute_child(self=<subprocess.Popen object>, args=['git.cmd', '--no-pager', 'log', '-1', '--pretty=format:"%ad|%an|%h|%H|%d"--abbrev-commit', '--date=iso'], executable='git.cmd', preexec_fn=None, close_fds=False, cwd='/shared/pywikipedia/rewrite', env=None, universal_newlines=False, startupinfo=None, creationflags=0, shell=False, p2cread=None, p2cwrite=None, c2pread=8, c2pwrite=9, errread=None, errwrite=None) 1247 if fd is not None: 1248 os.close(fd) => 1249 raise child_exception 1250 1251 child_exception = OSError(2, 'No such file or directory') <type 'exceptions.OSError'>: [Errno 2] No such file or directory args = (2, 'No such file or directory') child_traceback = 'Traceback (most recent call last):\n File "/usr/...st)\nOSError: [Errno 2] No such file or directory\n' errno = 2 filename = None message = '' strerror = 'No such file or directory' Basically, getversiondict() needs to be able to fail gracefully and return some kind of placeholder value if it isn't able to locate either a GIT or SVN version number, rather than throw an exception and stop the entire framework from executing.
@Russell Blau: This is irrelevant to this bug. It's about tools lab. Normally this problem would not occur because /usr/bin is in $PATH, so calling "git" has no problem. However, in tools web server, /usr/bin is not in $PATH. merely calling git therefore is not enough; we have to call /usr/bin/git. Do you think tools lab needs to reconfigure? I asked someone in IRC, and he said like don't solve the problem with $PATH.
Closing again as per comment 8, as the original bug reported in *this* report is fixed.
Well, I mean my comment is unrelated to the bug, not his comment. Anyway, since Merjin van Deen has filed another bug separately already, let's follow the other bug instead.
