Jeff Robbins wrote .. > re the 'subdir' directory: > > I've attached a screenshot from WinZip which I used to extract the .tgz > tarball. I sorted by directory so you can see that WinZip does not show > the > 'subdir' directory. Perhaps a flaw in WinZip? In any case, I didn't > knowingly delete that directory...I only inferred it existed from reading > the test code. Perhaps a stub file could be placed in 'subdir' to force > WinZip to see it? I realize that this may sound like the tail wagging > the > dog, but I think WinZip is common on Win32 platforms. If there's another > tool I should be using, I will comply!
It doesn't list test/modules either which is another empty directory, although I don't know what it is for at the moment. My guess is that you might have some option enabled in WinZIP which says ignore empty directories. It would seem sensible though to stick a dummy text file in subdir to make sure it stays around if certain options to WinZIP are going to cause it to disappear. Anyway, I'll check in the normpath change and add a dummy file for good measure. Thanks. BTW, what about the _pspmodule issue you talked about? Not sure how you would be able to run the tests successfully if that module wasn't being built. Graham > ----- Original Message ----- > From: "Graham Dumpleton" <[EMAIL PROTECTED]> > To: "Jeff Robbins" <[EMAIL PROTECTED]> > Cc: "python-dev list" <python-dev@httpd.apache.org> > Sent: Saturday, November 11, 2006 20:18 > Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 > > > > > > On 12/11/2006, at 12:31 AM, Jeff Robbins wrote: > > > >> 3 problems found on Win32: > >> > >> > >> 1) _psp didn't build and I don't know how to build it > > > > How are you trying to build mod_python in the first place? Are you using > > dist/build_installer.bat or using VisualStudio project file. The latter > > isn't > > really used any longer and isn't tested. We know that it doesn't list > the > > finfoobject.c file for a start. > > > >> 2) In the 'Testing PythonImport' test, the path separators in the two > >> paths being compared are different (no doubt due to Win32 backslash > vs > >> forward slash issues) > >> > >> the tests.py code does this: > >> directory = os.path.dirname(__file__) > >> assert(sys.path.count(directory) == 1) > >> > >> os.path.dirname(__file__) is 'C:\\work\\mod_python-3.3.0- > >> dev-20061109\\test\\htdocs' > >> > >> yet sys.path has this in it 'C:/work/mod_python-3.3.0-dev-20061109/ > >> test\\\\htdocs' > >> > >> so the assert fails since the first string can't be found in sys.path > >> (count == 0) > > > > If in test/test.py you change: > > > > c = Container(PythonPath("[r'%s']+sys.path" % DOCUMENT_ROOT), > > > > to: > > > > c = Container(PythonPath("[r'%s']+sys.path" % > > os.path.normpath(DOCUMENT_ROOT)), > > > > does it pass? > > > >> 3) in test_interpreter_per_directory() the code does this: > >> rsp = self.vhost_get("test_interpreter_per_directory", '/ > >> subdir/foo.py').upper() > >> > >> interpreter+'SUBDIR/' is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/ > >> TEST/HTDOCS/SUBDIR/' > >> rsp is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/TEST/HTDOCS/' > >> > >> I don't understand the tests.py code but it looks like in the > >> interpreter() code > >> def interpreter(req): > >> if req.phase == "PythonFixupHandler": > >> if req.filename[-1] != '/' and os.path.isdir(req.filename): > >> req.write(req.interpreter) > >> return apache.DONE > >> return apache.OK > >> else: > >> req.write(req.interpreter) > >> return apache.DONE > >> > >> perhaps the req.filename 'C:/work/mod_python-3.3.0-dev-20061109/ > >> test/htdocs/subdir' is supposed to pass the os.path.isdir() test...but > >> it doesn't. There is no 'subdir' folder under htdocs so on Win32, > >> os.path.isdir() returns False. Maybe this is an os dependency? > > > > The 'subdir' directory exists in the tarball. Any chance you accidentally > > deleted > > it somehow? Can you in a fresh directory unpack the tarball, verify > that > > the > > directory exists and then rebuild and retest? > > > > Graham > > > >