>> 2. Which Python do you use to run bin\test.py? I hope you're using
>> bin\python.exe for that attempt anyway.
> The one test.py refers to. (Yep, still tapping around blindly.)
I'm not following. "#!" lines don't mean anything on Windows, and
that's the only sense in which I can imagine test.py refers to a
Python. I showed exactly how I tried running them later in my msg:
Trying "bin\python.exe bin\test.py -v" from the build directory ...
although I didn't say there that I did that from a DOS (not Cygwin
bash shell) box. Then that explicitly names the Python that ships
with Zope. If you just try "bin\test.py" instead, you'll pick up
whatever Python installation you most recently happened to associate
with the .py extension. It's certainly better to use the Python Zope
will actually run with on Windows.
> ... which is why I intended to start putting the WinBuilders under the
> Zope tree for versioning, so It's always around in the correct
> (historic) version.
That's still a good idea, if you're asking me <wink>. That's what I
do, e.g., for ZRS (it has a WinBuilder subdirectory).
>> However, I don't think this _specific_ one is WinBuilder's fault.
>> When I look at Zope 2.8's setup.py, I see that nothing has been added
>> here: ...
> I thought so. But I'm not comfortable with prepping the setup.py
> unfortunately and some tries didn't work out, so I dropped it.
Someone with setup.py courage needs to step up to the plate then. The
Windows build process is way hard enough to follow already without
adding reams of arbitrary new makefile cruft to paper over setup.py
bugs. Perhaps someone on Linux could volunteer to run Zope trunk
tests from the result of doing "setup.py install ...", and add missing
files to setup.py until that works. The WinBuilders tests can't
possibly work either so long as setup.py neglects to install necessary
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -