RE: [ZODB-Dev] RE: RE: RE: PersistentMapping
[Thomas Lotze] > Tests... there are test suites for PersistentMapping both in > src/ZODB/tests/testPersistentMapping.py (which is the one that checkin > message talked about) and one in src/persistent/tests/test_mapping.py > (which I added when I found test_list.py, but no mapping tests in that > place). Now there are two test suites for persistent mapping, just as > there are for lists. In the case of lists it's even clearer than for > mappings that the duplication is unnecessary as the test code is more or > less the same. The tests in src/ZODB/tests were touched more recently > than those in src/persistent/tests according to svn, but IMO it's more > obvious to test lists and mappings close to where they are defined. What > to do about this? The best idea is to clean it up so that it makes good sense. There's lots of historical cruft in the ZODB code base that doesn't make much sense anymore. >> Looks like the 3.5 branch got overlooked. Merging rev 38076 from 3.4 >> branch to 3.5 branch would be fine. > This yields a large conflict in 3.5's NEWS.txt. Should I just leave it > untouched and not modify old news? "Old" news will become "new" news again, when the next micro release in the ZODB 3.5 line is made. 3.5.1 is current. All changes made now on the 3.5 branch will eventually show up in a 3.5.2 release, and NEWS.txt on the 3.5 branch should be changed to record those changes as they're made (the idea that a "release manager" is going to dig thru ZODB history to do this at the last second before a release is a fantasy -- won't happen). BTW, merges to NEWS-like files generally don't work well across branches. What to do instead: - Do the merge. - Do "svn revert NEWS.txt" to throw away the botched merged on that single file. - Edit NEWS.txt by hand, inserting branch-appropriate NEWS for what changed in the rest of the merge. Usually this amounts to just copying paragraphs from one NEWS.txt to another, changing version numbers in an obvious way. ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] RE: RE: RE: PersistentMapping
Tim Peters wrote: > Looks it got lost in the branches. PersistentMapping.__iter__ was added in > ZODB 3.4.2, just this August: > >http://mail.zope.org/pipermail/zodb-checkins/2005-August/010225.html > >Log message for revision 38076: >Gave PersistentMapping an __iter__ method. >Also gave it some tests (it was woefully untested). >... Tests... there are test suites for PersistentMapping both in src/ZODB/tests/testPersistentMapping.py (which is the one that checkin message talked about) and one in src/persistent/tests/test_mapping.py (which I added when I found test_list.py, but no mapping tests in that place). Now there are two test suites for persistent mapping, just as there are for lists. In the case of lists it's even clearer than for mappings that the duplication is unnecessary as the test code is more or less the same. The tests in src/ZODB/tests were touched more recently than those in src/persistent/tests according to svn, but IMO it's more obvious to test lists and mappings close to where they are defined. What to do about this? > Looks like the 3.5 branch got overlooked. Merging rev 38076 from 3.4 branch > to 3.5 branch would be fine. This yields a large conflict in 3.5's NEWS.txt. Should I just leave it untouched and not modify old news? -- Thomas ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] RE: RE: RE: PersistentMapping
[Christian Theune] > The whole testing story together with all the active branches and > platforms sounds like we want to have some buildbot clients for ZODB as > well. I could set up a buildbot client on Windows 2k and Linux to test > various ZODB branches ... > > That could be added to the Zope buildbot then ... Any oppinions? I think that's an excellent idea -- especially since the Zopes were fiddled recently to run far fewer tests. That means, in particular, that there's no longer any regular testing of ZODB (ZODB's test suite used to get run as part of running the Zope 2 and Zope 3 tests, but not anymore). ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] RE: RE: RE: PersistentMapping
Am Freitag, den 18.11.2005, 11:25 -0500 schrieb Tim Peters: > It's more likely due to people fiddling with zpkg. "setup.py build" _had_ > worked fine for running the tests for years, and I know it still worked fine > a few months ago. But I don't normally do that, so didn't notice when it > broke. It's not due to changes in ZODB code (no relevant changes have been > made there -- or at least none that I made ;-)). For whatever reason, looks > like "setup.py build" in ZODB simply ignores the existence of ZODB's > zope/testing directory now (but doesn't ignore ZODB's other zope/* > directories ...). > > ... The whole testing story together with all the active branches and platforms sounds like we want to have some buildbot clients for ZODB as well. I could set up a buildbot client on Windows 2k and Linux to test various ZODB branches ... That could be added to the Zope buildbot then ... Any oppinions? Cheers, Christian -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] RE: RE: RE: PersistentMapping
[Tim]
...
>> This worked (which is what I normally do): [build_ext -i]
[Thomas]
> It did for me too. I guess the crucial difference was doing build_ext
> instead of just build.
Yes.
> Maybe someone with more distutils clue could say something about it; if
> my guess is right, README.txt should be changed.
It's more likely due to people fiddling with zpkg. "setup.py build" _had_
worked fine for running the tests for years, and I know it still worked fine
a few months ago. But I don't normally do that, so didn't notice when it
broke. It's not due to changes in ZODB code (no relevant changes have been
made there -- or at least none that I made ;-)). For whatever reason, looks
like "setup.py build" in ZODB simply ignores the existence of ZODB's
zope/testing directory now (but doesn't ignore ZODB's other zope/*
directories ...).
...
>> I don't know what +1 means on other lists, but on this list it means
>> "that's such a good idea I'm going to devote my life to implementing it,
>> and I promise to finish it before this time next week" -- thanks ;-)
> Normalization of votes should definitely be standardized across lists.
I was pulling your leg -- +1 means the same thing here as elsewhere ("strong
yes, to the extent that I'll least argue in favor of it").
> But then, what does "implementing a deprecation" mean? If it's just
> adding a deprecation warning, I should be able to make it in time ;o)
It means adding the warning, documenting the deprecation in NEWS.txt, adding
a test to ensure that the deprecation warning is raised when appropriate,
and possibly a bunch of tedious hair to suppress the new warning(s) while
the tests that exercise the now-deprecated feature are running (while
deprecated, it's still supported until it goes away, so the tests for it
still need to run).
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] Re: RE: RE: PersistentMapping
Julien Anguenot wrote: > Note I added couple of weeks ago a comment about this within the > README.txt of ZODB. Ah, now that you mention it, I found it. I think it's too late in the file, you trip over the testing before you get to it. That is, I did. > % export PYTHONPATH=`pwd`/src:$PYTHONPATH That wasn't necessary for me. -- Thomas ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] RE: RE: RE: PersistentMapping
Tim Peters wrote: > Things I can't guess include which version of ZODB you're trying this > with, and exactly what the errors were. Copy+paste generally works a lot > better than English paraphrasing. Sorry. > From the "build/lib.foo" part I guess you're running on Linux. Right. > So I tried that just now using ZODB trunk. It failed too, but with > different symptoms than you're describing: > > $ python2.4 setup.py build > ... > $ python2.4 test.py -v > Running tests from build/lib.linux-i686-2.4 Traceback (most recent call > last): > File "test.py", line 40, in ? > from zope.testing import testrunner > ImportError: No module named zope.testing $ Well, as I wrote, I have the zope package from a current Zope3 trunk in my path. Oh, wait. I wrote this on #zope3-dev where I asked first. Sorry again, I confused myself by spreading over too many (i.e. more than one) media... Anyway, you don't seem to have Zope in your path, but I do. > This worked (which is what I normally do): It did for me too. I guess the crucial difference was doing build_ext instead of just build. Maybe someone with more distutils clue could say something about it; if my guess is right, README.txt should be changed. > It should also go in the Zope-2_7-branch branch of CVS module ZODB3 (which > will eventually become ZODB 3.2.11, for use in the Zope 2.7 line). Yes, you wrote that before, I just didn't quote it. I'd have to find out first whether I have write access to the CVS, though. > I don't know what +1 means on other lists, but on this list it means > "that's such a good idea I'm going to devote my life to implementing it, > and I promise to finish it before this time next week" -- thanks ;-) Normalization of votes should definitely be standardized across lists. But then, what does "implementing a deprecation" mean? If it's just adding a deprecation warning, I should be able to make it in time ;o) -- Thomas ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
