Jeff Robbins wrote .. > Graham, > > I couldn't find a WinZip option that controls this. It must be a bug in > its > tar support, since I know it supports empty native windows directories > just > fine.
It may well be a bug. At: http://dsd.lbl.gov/firefish/install.html it warns: Due too an obscure bug, Winzip and possibly other Windows decompression tools may miss empty directories such as tomcat/logs from tar[.gz] files. Consequently, use the .zip download file on Windows, and DO NOT decompress tar[.gz] files on Windows. There is also the comment at: http://www.cygwin.com/ml/cygwin/2000-11/msg01493.html which says: The only archiver I know which ignores empty directories is WinZip. Don't use WinZip on tar files. I'll just add the dummy file and avoid the whole issue even if a newer version of WinZIP may address the problem. Graham > ----- Original Message ----- > From: "Graham Dumpleton" <[EMAIL PROTECTED]> > To: "python-dev list" <python-dev@httpd.apache.org> > Sent: Sunday, November 12, 2006 20:12 > Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 > > > > 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 > >> > > >> > > >
