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@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com