Hi Martijn
> Betreff: [Zope3-dev] Re: AW: relying on win32api in windows
> supportofzc.zope3recipes
>
> 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. :)
Yeah, good idea probably he can ask him. I think he know
Mark Hammond.
> > 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.
I'm not sure if my wiondows test setup broke something on
linux. Stephan Richter tested it and was telling me that
the tests are fine.
> 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.
Hehe, I was nearly going crazy as I wrote this part.
I see the difference in update on linux and uninstall/install
on windows. I'm not sure what's going on there.
The reason for a update or un/install ist driven by the
buildout. If buildout recognizes that the checkout or
a script is changing, a un/install get used. I buildout
thinks nothing get changed a update will be used.
As far as I can see, this is based on the return value
of the install or update method. If this method regonizes
another output then the last one (in the last buildout run),
a un/install process get used. if the return value is
still the same, a update process get used.
I'm not sure how buildout can find out the difference
between the buildout runs. I guess this is based on the
history.cfg file. I didn't fully introspect this part
as I wrote the windows implementation. Probably we need
to take a second look at what is the difference of the
update or install method if they run on linux or windows.
Regards
Roger Ineichen
> Regards,
>
> Martijn
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub:
> http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch
>
>