[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