Windows Binaries for 2.8b1
Hi, and again, I got to complain about building Zope on Windows. This time it's the 2.8 branch again with the 2.8b1 release. It looks like the WinBuilders aren't taken care for at all. The ZClass tests didn't got into the procedure of getting packaged so I had to copy those files manually for running the tests. Then the doctest module doesn't comply with platform independent handling of path names using 'variable.split("/")' and relatives. The now running tests fail pretty much in various places (Catalog, ZODB, ...) I'm not able to do any work on this as I'm lacking time. I took the job of building the releases as long as it's pressing the "do it now button" and running the tests seeing them pass. I did not take the job of cleaning up Zope for Windows. The WinBuilders are a really annoying thing, I'm glad they went away for Zope3. To notice: Zope 2.8a1 has not been available as Windows release and neither will be 2.8b1. You really want to blindly go forward for an RC not having a single external user running any 2.8 release at all? I'm pretty annoyed right now. Cheers, Christian -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct@gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development
On Mon, 25 Apr 2005 10:54:23 +0200, Christian Theune <ct@gocept.com> wrote:
Hi,
and again, I got to complain about building Zope on Windows. This time it's the 2.8 branch again with the 2.8b1 release.
It looks like the WinBuilders aren't taken care for at all. The ZClass tests didn't got into the procedure of getting packaged so I had to copy those files manually for running the tests. Then the doctest module doesn't comply with platform independent handling of path names using 'variable.split("/")' and relatives.
The now running tests fail pretty much in various places (Catalog, ZODB, ...)
I'm not able to do any work on this as I'm lacking time. I took the job of building the releases as long as it's pressing the "do it now button" and running the tests seeing them pass. I did not take the job of cleaning up Zope for Windows. The WinBuilders are a really annoying thing, I'm glad they went away for Zope3.
To notice: Zope 2.8a1 has not been available as Windows release and neither will be 2.8b1. You really want to blindly go forward for an RC not having a single external user running any 2.8 release at all?
I'm pretty annoyed right now.
Cheers, Christian
I wanted to look a bit into this, but quickly ran into problems. I checked out WinBuilders and Zope 2.8. I was easily able to use inst/configure.py and nmake to compile and install Zope. But how do I generate the Zope.tgz needed for WinBuilders? Will WinBuilders work with InnoSetup 5.0.8? Regards, Florian Schulze
Am Montag, den 25.04.2005, 12:21 +0200 schrieb Florian Schulze:
I wanted to look a bit into this, but quickly ran into problems. I checked out WinBuilders and Zope 2.8. I was easily able to use inst/configure.py and nmake to compile and install Zope. But how do I generate the Zope.tgz
A tar-packed source checkout is ok.
needed for WinBuilders? Will WinBuilders work with InnoSetup 5.0.8?
Not AFAIK. Cheers, CHristian -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct@gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development
[Christian Theune]
and again, I got to complain about building Zope on Windows. This time it's the 2.8 branch again with the 2.8b1 release.
It looks like the WinBuilders aren't taken care for at all.
AFAIK, nobody looks at WinBuilders between releases. It's traditionally been the job of whoever builds the Windows installer to sort out whatever troubles WinBuilders has gotten into since the last release. Certainly most Linux contributors aren't even aware of WinBuilder's existence.
The ZClass tests didn't got into the procedure of getting packaged so I had to copy those files manually for running the tests. Then the doctest module doesn't comply with platform independent handling of path names using 'variable.split("/")' and relatives.
The now running tests fail pretty much in various places (Catalog, ZODB, ...)
What exactly do you do to "run tests"? This is exactly what I do: svn up python setup.py build_ext -i python test.py -vv --all The same two tests have been failing on Windows that way since last October, but all other tests pass. BTW, I don't have a guess about what your doctest complaint is. Since, e.g., all the doctest-based tests _do_ pass from a checkout, hard to guess what you're saying there. It's documented that, e.g., relative paths passed to DocFileSuite must use '/' as the path separator, and AFAIK all the code that's checked in does do that. I don't know of any other piece of doctest that cares about path separators.
I'm not able to do any work on this as I'm lacking time. I took the job of building the releases as long as it's pressing the "do it now button"
Or in the case of WinBuilders, a few dozen buttons, shell scripts, makefiles, and tricks building on 1.6 gigabytes of Cygwin code <wink>.
and running the tests seeing them pass. I did not take the job of cleaning up Zope for Windows. The WinBuilders are a really annoying thing, I'm glad they went away for Zope3.
Came with costs too, though. For example, Zope3 on Windows doesn't include Python, doesn't include the Python Windows extensions, and comes with no support for running as a Windows service. You might think that people who value that stuff would contribute something toward making it happen, but in project after project in the Open Source world it's difficult to attract Windows contributors.
To notice: Zope 2.8a1 has not been available as Windows release and neither will be 2.8b1. You really want to blindly go forward for an RC not having a single external user running any 2.8 release at all?
I suspect it's worse than just that. When the two tests in collector 1728 started failing last October on Windows, I noted at the time that "FYI, on WinXP, Zope 2.8 appears to use localhost no matter what ip-address is set to in zope.conf". No reason to suspect that got better, since the two failing tests that inspired that little investigation are still failing.
I'm pretty annoyed right now.
Cheers,
I just liked the contrast in those two lines <wink>.
LOL -- the attempt to send my last msg to Christian from my gmail account got blocked: This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: ct@gocept.com Technical details of permanent failure: PERM_FAILURE: SMTP Error (state 9): 553 5.3.0 Spam blocked see: http://spamcop.net/bl.shtml?64.233.184.203 ----- Original message ----- Received: by 10.54.47.20 with SMTP id u20mr2106929wru; Mon, 25 Apr 2005 13:37:01 -0700 (PDT) Received: by 10.54.46.75 with HTTP; Mon, 25 Apr 2005 13:37:01 -0700 (PDT) Message-ID: <1f7befae050425133730b456f4@mail.gmail.com> Date: Mon, 25 Apr 2005 16:37:01 -0400 From: Tim Peters <tim.peters@gmail.com> Reply-To: Tim Peters <tim.peters@gmail.com> To: Christian Theune <ct@gocept.com> Subject: Re: [Zope-dev] Windows Binaries for 2.8b1 Cc: zope-dev@zope.org ----- Message truncated ----- You should really be using SpamBayes <0.9 wink>.
Tim Peters <tim.peters@gmail.com> wrote:
LOL -- the attempt to send my last msg to Christian from my gmail account got blocked:
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
ct@gocept.com
Technical details of permanent failure: PERM_FAILURE: SMTP Error (state 9): 553 5.3.0 Spam blocked see: http://spamcop.net/bl.shtml?64.233.184.203
Yeah this goes to show that you have to be extremely careful in choosing your RBL sources... And that spamcop is definitely not a good one. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
On Apr 26, 2005, at 2:22, Florent Guillaume wrote:
Tim Peters <tim.peters@gmail.com> wrote:
Technical details of permanent failure: PERM_FAILURE: SMTP Error (state 9): 553 5.3.0 Spam blocked see: http://spamcop.net/bl.shtml?64.233.184.203
Yeah this goes to show that you have to be extremely careful in choosing your RBL sources... And that spamcop is definitely not a good one.
Not true. I've been using SpamCop for years now and had exactly four addresses that required me to create exceptions for them because their SMTP server got listed. I see what gets rejected because my Postfix sends me email about it, so I retain full control over the situation. jens
Great. And the current situation doesn't even catch too much spam. We're relying on some central spam filtering infrastructure here. Looks like I got to tune it again... Am Montag, den 25.04.2005, 17:46 -0400 schrieb Tim Peters:
You should really be using SpamBayes <0.9 wink>.
-- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct@gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development
Howdy, Am Montag, den 25.04.2005, 16:37 -0400 schrieb Tim Peters:
AFAIK, nobody looks at WinBuilders between releases. It's traditionally been the job of whoever builds the Windows installer to sort out whatever troubles WinBuilders has gotten into since the last release. Certainly most Linux contributors aren't even aware of WinBuilder's existence.
Which isn't actually a good idea I suppose. Relying on a fragile infrastructure to find out it doesn't work when you need it. Well...
What exactly do you do to "run tests"? This is exactly what I do:
svn up python setup.py build_ext -i python test.py -vv --all
I go to the build directory of the WinBuilders and run bin/test.py
The same two tests have been failing on Windows that way since last October, but all other tests pass.
BTW, I don't have a guess about what your doctest complaint is. Since, e.g., all the doctest-based tests _do_ pass from a checkout, hard to guess what you're saying there. It's documented that, e.g., relative paths passed to DocFileSuite must use '/' as the path separator, and AFAIK all the code that's checked in does do that. I don't know of any other piece of doctest that cares about path separators.
Hmm. Then it might have only be the missing files. I just have a really hard time trying to poke into that stuff and make it work. It just feels like poking a hairy cat.
Or in the case of WinBuilders, a few dozen buttons, shell scripts, makefiles, and tricks building on 1.6 gigabytes of Cygwin code <wink>.
Well. It's not that bad if it would work. - bumping a version number - run "WinBuilders/buildout zope" - do "build/bin/test.py" - Upload the .exe file
I suspect it's worse than just that. When the two tests in collector 1728 started failing last October on Windows, I noted at the time that "FYI, on WinXP, Zope 2.8 appears to use localhost no matter what ip-address is set to in zope.conf". No reason to suspect that got better, since the two failing tests that inspired that little investigation are still failing.
Looks like the pain we go through is really wanted. I hate it when the estimated number of unknown cases (that appreciate the Windows installers) is high.
I just liked the contrast in those two lines <wink>.
Human contradictions. I'm happy with them. Kind of sanity test for me. ;) Christian -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct@gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development
... [Tim Peters]
What exactly do you do to "run tests"? This is exactly what I do:
svn up python setup.py build_ext -i python test.py -vv --all
[Christian Theune]
I go to the build directory of the WinBuilders and run bin/test.py
1. Is there a reason to _expect_ that to work? The WinBuilders README.txt doesn't claim that it should. Would sure be nice if it did work. 2. Which Python do you use to run bin\test.py? I hope you're using bin\python.exe for that attempt anyway. 3. How did you get that far? When I change a current WinBuilders checkout to point at Zope-2.8.0-b1.tgz, doing: WinBuilders/buildout zope dies like so: """ ... Zope binaries installed successfully. Now run '"c:\Code\build\bin\python.exe" c:\Code\build\bin\mkzopeinstance.py' touch "/cygdrive/c/Code/build/lib/python/Zope/Startup/run.py" touch: cannot touch `/cygdrive/c/Code/build/lib/python/Zope/Startup/run.py': No such file or directory make: *** [/cygdrive/c/Code/build/lib/python/Zope/Startup/run.py] Error 1 """ And indeed, there is no Startup directory under lib/python/zope in SVN trunk. Which version of WinBuilders are you using? (I used current CVS HEAD) I can get beyond that by editing three lines in mk\zope.mk to refer to Zope2/Startup instead of Zope/Startup. Then the make completes. Trying "bin\python.exe bin\test.py -v" from the build directory then doesn't get anywhere, crapping out at once because (as I think you implied before) build\lib\python\ZClasses\_pmc.txt doesn't exist.
... Hmm. Then it might have only be the missing files. I just have a really hard time trying to poke into that stuff and make it work. It just feels like poking a hairy cat.
It's related to this:
Or in the case of WinBuilders, a few dozen buttons, shell scripts, makefiles, and tricks building on 1.6 gigabytes of Cygwin code <wink>.
Well. It's not that bad if it would work.
- bumping a version number - run "WinBuilders/buildout zope" - do "build/bin/test.py" - Upload the .exe file
It is that simple for a given release, _after_ the kinks specific to that release have been worked out. But it can't stay that simple across releases because we massively rearrange code for the Windows release, trying to make a single directory under which everything on Earth lives (alll of Zope, our own Python, our own pywin32 extensions). The way that's stitched together requires sorting out all the messy interactions among a large pile of shell scripts, makefiles, and tricks, so you get sucked into all of that stuff when anything "new" happens. Like ZClasses growing important .txt, and even .fs, files, since the last release. 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: # ZClasses setup( name='ZClasses', author=AUTHOR, packages=['ZClasses'], data_files=[['ZClasses', ['ZClasses/*.gif']], ['ZClasses/dtml', ['ZClasses/dtml/*']]], ) to record that ZClasses (or at least its tests) now requires some .txt and .fs files. That WinBuilders didn't copy those files to the build tree appears to be just a consequence of that "setup.py install" doesn't know anything about these new files (WinBuilders does an "install" to get the appropriate files copied from its src/ directory to its build/ directory). If so, that's an all-platform bug in Zope trunk's setup.py, but one that isn't visible in daily checkout testing. BTW, it's also traditional that the person building the Windows installer find and fix the new bugs in Zope's setup.py <wink>.
Howdy, Am Dienstag, den 26.04.2005, 11:38 -0400 schrieb Tim Peters:
[Christian Theune]
I go to the build directory of the WinBuilders and run bin/test.py
1. Is there a reason to _expect_ that to work? The WinBuilders README.txt doesn't claim that it should. Would sure be nice if it did work.
Dunno. I'm tapping in the dark there. That's the runner I use for ages on Linux and it was around on the windows build. So I started using it and it worked (for a while).
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.)
3. How did you get that far? When I change a current WinBuilders checkout to point at Zope-2.8.0-b1.tgz, doing:
Which version of WinBuilders are you using? (I used current CVS HEAD)
A local version that already contains the fixes described by you. The box I use it on isn't configured to be able to talk to the Zope CVS/SVN so I wanted to make this work and then put it back to the repository.
It is that simple for a given release, _after_ the kinks specific to that release have been worked out. But it can't stay that simple across releases because we massively rearrange code for the Windows release, trying to make a single directory under which everything on Earth lives (alll of Zope, our own Python, our own pywin32 extensions). The way that's stitched together requires sorting out all the messy interactions among a large pile of shell scripts, makefiles, and tricks, so you get sucked into all of that stuff when anything "new" happens. Like ZClasses growing important .txt, and even .fs, files, since the last release.
... 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.
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.
to record that ZClasses (or at least its tests) now requires some .txt and .fs files. That WinBuilders didn't copy those files to the build tree appears to be just a consequence of that "setup.py install" doesn't know anything about these new files (WinBuilders does an "install" to get the appropriate files copied from its src/ directory to its build/ directory). If so, that's an all-platform bug in Zope trunk's setup.py, but one that isn't visible in daily checkout testing.
Feels like that. That's why I'm running the tests from the result of the WinBuilders!
BTW, it's also traditional that the person building the Windows installer find and fix the new bugs in Zope's setup.py <wink>.
Great. I didn't read that job description well enough. Theuni-the-blind-windows-monkey -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct@gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development
[Tim]
2. Which Python do you use to run bin\test.py? I hope you're using bin\python.exe for that attempt anyway.
[Christian]
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 files.
Tim Peters wrote:
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 files.
Done. (besides the Zope 3 failures) I did that more than once, but why can't people clean up after themselves? AFAICS two things could help them: - giving feedback by running nightly test on a not-in-place installation - reducing the need for setup.py updates by switching to the Zope 3 setup code Just my 2 cents. Yuppie
[Tim Peters]
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 files.
[yuppie]
Done. (besides the Zope 3 failures)
Thank you!
I did that more than once,
Did what more than once?
but why can't people clean up after themselves?
Which people, cleaning up what? Sorry, I'm not following this.
AFAICS two things could help them:
- giving feedback by running nightly test on a not-in-place installation
That would be helpful.
- reducing the need for setup.py updates by switching to the Zope 3 setup code
I think this gets worse with Zope3 code, and especially when mixed in with Zope2. Zope3 still uses setup.py for testing from a checkout, but uses zpkgtools for building a distribution: those two subsystems have nothing in common, and get out of synch with each other. It would be better if Z3's setup.py used zpkgtools too, but it doesn't now. In any case, nothing in Z2 (including WinBuilders) knows anything about how to live with zpkgtools now. For Zope 2.8, there may not be a realistic alternative to teaching Zope 2.8's setup.py how to install the Z3 bits in Zope 2.8. It already does this for other pieces. For example, ZODB 3.4 (which Zope 2.8 uses) inherited the same setup.py-vs-zpkgtools schizophrenia from Zope3, but Zope 2.8's setup.py learned how to install ZODB 3.4 independent of that (indeed, ZODB's own setup.py has never been part of any Zope checkout that I know of).
Hi! Tim Peters wrote:
[yuppie]
I did that more than once,
Did what more than once?
Updating setup.py. (Or reminding people to do it themselves if they add new files and forget to update setup.py.)
but why can't people clean up after themselves?
Which people, cleaning up what? Sorry, I'm not following this.
Contributers. setup.py.
AFAICS two things could help them:
- giving feedback by running nightly test on a not-in-place installation
That would be helpful.
- reducing the need for setup.py updates by switching to the Zope 3 setup code
I think this gets worse with Zope3 code, and especially when mixed in with Zope2. Zope3 still uses setup.py for testing from a checkout, but uses zpkgtools for building a distribution: those two subsystems have nothing in common, and get out of synch with each other. It would be better if Z3's setup.py used zpkgtools too, but it doesn't now. In any case, nothing in Z2 (including WinBuilders) knows anything about how to live with zpkgtools now.
For Zope 2.8, there may not be a realistic alternative to teaching Zope 2.8's setup.py how to install the Z3 bits in Zope 2.8. It already does this for other pieces. For example, ZODB 3.4 (which Zope 2.8 uses) inherited the same setup.py-vs-zpkgtools schizophrenia from Zope3, but Zope 2.8's setup.py learned how to install ZODB 3.4 independent of that (indeed, ZODB's own setup.py has never been part of any Zope checkout that I know of).
Seems I wasn't specific enough. I just meant setup.py, not the other setup code from Zope 3. The Zope 2 code requires to specify each directory. The Zope 3 code walks through all subdirectories and searchs for files with the specified file extensions. That code is already part of the Zope 2 setup.py, but only used for the Zope 3 stuff. I didn't try it, but I guess it would not be too hard to use it for all the other packages as well. Cheers, Yuppie
Tim Peters wrote:
[Tim Peters]
...
I think this gets worse with Zope3 code, and especially when mixed in with Zope2. Zope3 still uses setup.py for testing from a checkout, but uses zpkgtools for building a distribution: those two subsystems have nothing in common, and get out of synch with each other. It would be better if Z3's setup.py used zpkgtools too, but it doesn't now.
Yup. We encountered this pain in working on the 3.1 release. I'm hoping to spend some time with Fred tomorrow to see if we can make a checkout use more of zpkgtools. zpkgtools is still a work in progress though. I expect we'll evolve it a bit more in the course of the 3.1 release.
In any case, nothing in Z2 (including WinBuilders) knows anything about how to live with zpkgtools now.
Yup. I'd like to fix this for 2.9. :) Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Hi, Am Dienstag, den 26.04.2005, 12:57 -0400 schrieb Tim Peters:
[Tim]
2. Which Python do you use to run bin\test.py? I hope you're using bin\python.exe for that attempt anyway.
[Christian]
The one test.py refers to. (Yep, still tapping around blindly.)
I'm not following. "#!" lines don't mean anything on Windows, and
I think cygwin does. But still you're right. I'll refer to it explicitly in the future.
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).
I'm just trying to get that stuff working at least once, then I'll drop it in.
Someone with setup.py courage needs to step up to the plate then. The [...] possibly work either so long as setup.py neglects to install necessary files.
Yuppie did, so I'll push out the stuff I have now. Andreas: Can you please consider a beta2 instead of a rc as the next step? Thanks. I promise to try running the test before the tag then. Cheers, Christian -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct@gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development
[Tim]
2. Which Python do you use to run bin\test.py? I hope you're using bin\python.exe for that attempt anyway.
[Christian]
The one test.py refers to. (Yep, still tapping around blindly.)
[Tim]
I'm not following. "#!" lines don't mean anything on Windows, and
[Christian]
I think cygwin does. But still you're right. I'll refer to it explicitly in the future.
Yes, cygwin pays attention to #!, but we _certainly_ don't want to test the code going into the Windows installer using Cygwin's Python -- the Windows installer installs an entirely different Python (Zope2 repackages and installs the native Windows Python from python.org). That's why it's a good idea too to do all testing from a DOS box; getting any part of Cygwin into the testing means it's testing stuff we're not shipping. [on a WinBuilder subdirectory]
I'm just trying to get that stuff working at least once, then I'll drop it in.
Good plan.
Someone with setup.py courage needs to step up to the plate then. The [...] possibly work either so long as setup.py neglects to install necessary files.
Yuppie did
That's not my understanding. My understanding (confirmed by eyeballing the checkins) is that Yuppie changed setup.py to add some test files used by ZClasses and ZODB, but left the failing tests in the Zope3 part of the code broken. I expect setup.py needs more changes to get those working.
so I'll push out the stuff I have now.
Good enough for now, I agree.
Andreas: Can you please consider a beta2 instead of a rc as the next step? Thanks.
I would if I were him.
I promise to try running the test before the tag then.
It probably helps if you're in the same time zone as Andreas. He always does things half a day before the earliest I expect him to do them <0.9 wink>.
[Tim]
Someone with setup.py courage needs to step up to the plate then. The [...] possibly work either so long as setup.py neglects to install necessary files.
[Christian]
Yuppie did
[Tim]
That's not my understanding. My understanding (confirmed by eyeballing the checkins) is that Yuppie changed setup.py to add some test files used by ZClasses and ZODB, but left the failing tests in the Zope3 part of the code broken. I expect setup.py needs more changes to get those working.
FYI, I repaired those tonight. At least 6 necessary files from the Zope3 code were missed by "setup.py install", covering three extensions (.rst, .request, .response), and one file with no extension at all ('png'). The only tests that fail from a WinBuilders build/ directory now (well, after changing CVS HEAD to use the right Zope version number, and editing 3 lines to look for Startup in Zope2) are the 2 tests that have been failing on Windows since last October. I can't make time to dig into those; for that matter, I couldn't make time to look at setup.py either <0.9 wink>.
--On Dienstag, 26. April 2005 23:55 Uhr +0200 Christian Theune <ct@gocept.com> wrote:
Andreas: Can you please consider a beta2 instead of a rc as the next step? Thanks.
You mean 2.8 b2? The next scheduled 2.8 release is b2 according to the posted release plan *wink*. -aj
Sticking to this thread ... Now the unit tests look like this: ====================================================================== ERROR: testCorrectFactories (zope.app.publisher.browser.tests.test_directoryreso urce.Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\zope\build_28\build\lib\python\zope\app\publisher\browser \tests\test_ directoryresource.py", line 107, in testCorrectFactories file = resource['png'] File "c:\zope\build_28\build\lib\python\zope\app\publisher\browser \directoryre source.py", line 77, in __getitem__ raise KeyError, name KeyError: 'png' ====================================================================== ERROR: test_dochttp (zope.app.tests.test_dochttp.Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\zope\build_28\build\lib\python\zope\app\tests \test_dochttp.py", line 120, in test_dochttp dochttp(['-p', 'test', directory]) File "c:\zope\build_28\build\lib\python\zope\app\tests\dochttp.py", line 75, i n dochttp names = [name[:-len(".request")] WindowsError: [Errno 3] Das System kann den angegebenen Pfad nicht finden: 'c:\\ zope\\build_28\\build\\lib\\python\\zope\\app\\tests\\recorded/*.*' ====================================================================== FAIL: test_http_factory (ZServer.tests.test_config.ZServerConfigurationTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\zope\build_28\build\lib\python\ZServer\tests\test_config.py", line 11 0, in test_http_factory self.assertEqual(server.ip, '127.0.0.1') File "c:\zope\build_28\build\bin\lib\unittest.py", line 302, in failUnlessEqua l raise self.failureException, \ AssertionError: 'localhost' != '127.0.0.1' ====================================================================== FAIL: test_webdav_source_factory (ZServer.tests.test_config.ZServerConfiguration TestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\zope\build_28\build\lib\python\ZServer\tests\test_config.py", line 12 8, in test_webdav_source_factory self.assertEqual(server.ip, '127.0.0.1') File "c:\zope\build_28\build\bin\lib\unittest.py", line 302, in failUnlessEqua l raise self.failureException, \ AssertionError: 'localhost' != '127.0.0.1' ====================================================================== FAIL: Doctest: zope.app.onlinehelp.onlinehelptopic.OnlineHelpTopic ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\zope\build_28\build\lib\python\zope\testing\doctest.py", line 2102, i n runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for zope.app.onlinehelp.onlinehelptopic.Onli neHelpTopic File "c:\zope\build_28\build\lib\python\zope\app\onlinehelp \onlinehelptopic.py ", line 72, in OnlineHelpTopic ---------------------------------------------------------------------- File "c:\zope\build_28\build\lib\python\zope\app\onlinehelp \onlinehelptopic.py", line 122, in zope.app.onlinehelp.onlinehelptopic.OnlineHelpTopic Failed example: topic = OnlineHelpTopic('help','Help',path,'') Exception raised: Traceback (most recent call last): File "c:\zope\build_28\build\lib\python\zope\testing\doctest.py", line 131 5, in __run compileflags, 1) in test.globs File "<doctest zope.app.onlinehelp.onlinehelptopic.OnlineHelpTopic[16]>", line 1, in ? topic = OnlineHelpTopic('help','Help',path,'') File "c:\zope\build_28\build\lib\python\zope\app\onlinehelp \onlinehelptopi c.py", line 163, in __init__ raise ConfigurationError( ConfigurationError: Help Topic definition c:\zope\build_28\build\lib \python\ zope\app\onlinehelp\tests\help.rst does not exist ---------------------------------------------------------------------- File "c:\zope\build_28\build\lib\python\zope\app\onlinehelp \onlinehelptopic.py", line 125, in zope.app.onlinehelp.onlinehelptopic.OnlineHelpTopic Failed example: topic.type Expected: 'zope.source.rest' Got: 'zope.source.stx' ---------------------------------------------------------------------- Ran 5634 tests in 1433.151s FAILED (failures=3, errors=2) Any comments? Still hesitating to release the binaries, but I have them around. -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct@gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development
Sticking to this thread ...
Now the unit tests look like this:
The Zope trunk test_http_factory and test_webdav_source_factory tests have been failing on Windows this way since last October (even when running tests from a checkout tree). See: http://www.zope.org/Collectors/Zope/1728 for those. I haven't seen the other failures before. The obvious guess for ConfigurationError: Help Topic definition c:\zope\build_28\build\lib\python\ zope\app\onlinehelp\tests\help.rst does not exist is that the help.rst file in question didn't get copied to the build tree, right? That is, another setup.py oversight.
FAILED (failures=3, errors=2)
That seems remarkably good, considering ...
Christian Theune wrote:
Sticking to this thread ...
[...]
---------------------------------------------------------------------- Ran 5634 tests in 1433.151s
FAILED (failures=3, errors=2)
Any comments? Still hesitating to release the binaries, but I have them around.
I changed setup.py to add the files you added manually. Besides the 2 ZServer tests the same tests fail on Linux. The setup code for the Zope 3 stuff works different and I don't want to fork it. So these errors should be discussed with the Zope 3 people. I think you should release what you have now. But for the next beta these errors should be release blockers. Maybe you can run Windows tests *before* Andreas tags the next beta release? Cheers, Yuppie
participants (8)
-
Andreas Jung -
Christian Theune -
Florent Guillaume -
Florian Schulze -
Jens Vagelpohl -
Jim Fulton -
Tim Peters -
yuppie