[Zope3-dev] Re: AW: relying on win32api in windows support ofzc.zope3recipes

Martijn Faassen faassen at startifact.com
Fri Aug 17 07:00:00 EDT 2007


Hey Roger,

Roger Ineichen wrote:
[snip]
>> Was the original way to run Zope 3 trunk dependent on win32api?
> 
> I guess, but I'm not sure;
> Python 2.5 includes ctypes which could be used as a 
> replacement for the win32 part.

I am fine with requiring win32api, though it'd be better if it were 
indeed installable from the python package index. Otherwise you need to 
tell people to install two things (Python and win32api) instead of one 
thing on Windows in order to be able to install Zope 3. Who will 
volunteer to bug Mark Hammond? Perhaps Sidnei can, he's a Windows native. :)

> To some previous questions in this thread. 
> 
> I'm fine with any improvements and doctest cleanup. My 
> problem was, that I couldn't really merge the linux tests 
> into one document because I didn't had a linux box 
> when I wrote the implementation for testing.

Right, testing on multiple platforms isn't easy. I had the same problem 
but in reverse - trouble getting it set up in Windows.

> I agree with the maintainance overhead. That's bad.
> 
> I also recognized the buildout difference in the tests. I guess
> the egg version is older then the version then I used from the 
> trunk. I guess again, I think Jim did some improvments in 
> buildout and didn't change the tests in zope3recipe.
> 
> Could this be the case?

The more I look into it, the less I understand. I've just confirmed that 
on Linux and Windows both, the test runner is using zc.buildout-1.0.0b28 
  - the same version.

The Windows tests run successfully for me with that buildout version. So 
do the Linux tests!

On Windows I do get a lot of output involving import errors of 'tests' 
modules from various eggs (zdaemon, zope.testing, zconfig, etc, 
basically it seems any package on the path). I already reported this 
behavior to Jim. Did you see this too? Anyway, this did not appear to 
have affected the finding or running of the tests themselves on Windows.

It isn't some other egg either, you'd think: the sys.path setting in the 
'test' script points to the exact same versions of the eggs on both 
platforms:

sys.path[0:0] = [
   '/home/faassen/buildout/zc.zope3recipes',
   '/home/faassen/buildout-eggs/zope.testing-3.5.1-py2.4.egg',
   '/home/faassen/bin/eggs/setuptools-0.6c6-py2.4.egg',
   '/home/faassen/buildout-eggs/zc.recipe.filestorage-1.0a5-py2.4.egg',
   '/home/faassen/buildout-eggs/zdaemon-2.0.0-py2.4.egg',
   '/home/faassen/buildout-eggs/ZConfig-2.4a6-py2.4.egg',
   '/home/faassen/buildout-eggs/zc.recipe.egg-1.0.0b6-py2.4.egg',
   '/home/faassen/bin/eggs/zc.buildout-1.0.0b28-py2.4.egg',
   ]

This is very mysterious. The Linux tests expect lines like this:

     Generated script '/sample-buildout/bin/instance'.

And the Windows tests expect that line not to be there.

Also, the Linux tests have this sequence:

     >>> print system(join('bin', 'buildout')),
     Develop: '/sample-buildout/demo1'
     Develop: '/sample-buildout/demo2'
     Updating database.
     Updating myapp.
     Updating instance.
     Installing instance2.
     Generated script '/root/etc/init.d/myapp-run-instance2'.

And the Windows tests expect this:

     >>> print system(join('bin', 'buildout')),
     Develop: '/sample-buildout/demo1'
     Develop: '/sample-buildout/demo2'
     Uninstalling instance.
     Updating database.
     Updating myapp.
     Installing instance.
     Installing instance2.
     Generated script '/root/etc/init.d/myapp-run-instance2'.

Where Linux has "Updating instance", Windows has "Uninstalling instance" 
and then following it "Installing instance".

Oddly enough the "Generated script" bit *is* expected in Windows here 
(as in many other places).

I really don't understand what's going on here at all and it's no wonder 
you also had issues.

Regards,

Martijn



More information about the Zope3-dev mailing list