[Zope-Checkins] SVN: Zope/trunk/ Added an allpy interpreter that has the same egg set as the alltests script. Changed the checknew script to check all packages found on sys.path, instead of only direc
Log message for revision 101376:
Added an allpy interpreter that has the same egg set as the alltests script.
Changed the checknew script to check all packages found on sys.path, instead of
only direct dependencies of Zope2. Otherwise we'll miss out on new releases
from the test-only dependencies
Changed:
U Zope/trunk/alltests.cfg
U Zope/trunk/inst/checknew.py
-=-
Modified: Zope/trunk/alltests.cfg
===
--- Zope/trunk/alltests.cfg 2009-07-01 16:32:55 UTC (rev 101375)
+++ Zope/trunk/alltests.cfg 2009-07-01 17:24:10 UTC (rev 101376)
@@ -3,7 +3,7 @@
[buildout]
extends = buildout.cfg
-parts += alltests
+parts += alltests allpy
[alltests]
recipe = zc.recipe.testrunner
@@ -83,3 +83,10 @@
defaults = ['--module', '!^(zope[.]app)[.]']
+
+
+[allpy]
+recipe = zc.recipe.egg
+eggs = ${alltests:eggs}
+interpreter = allpy
+scripts = allpy
Modified: Zope/trunk/inst/checknew.py
===
--- Zope/trunk/inst/checknew.py 2009-07-01 16:32:55 UTC (rev 101375)
+++ Zope/trunk/inst/checknew.py 2009-07-01 17:24:10 UTC (rev 101376)
@@ -10,25 +10,31 @@
print 'Setting socket time out to %d seconds' % 3
socket.setdefaulttimeout(3)
-ws = pkg_resources.require('Zope2')
-pi = PackageIndex()
+env = pkg_resources.Environment()
+env.scan()
names = []
installed = []
-for dist in ws:
-name = dist.project_name
-if name not in names:
-names.append(name)
-installed.append(dict(
-dist=dist,
-name=name,
-req=parse_requirements(name).next(),
-))
+for name in env:
+if name == 'python':
+continue
+distributions = env[name]
+for dist in distributions:
+name = dist.project_name
+if name not in names:
+names.append(name)
+installed.append(dict(
+dist=dist,
+name=name,
+req=parse_requirements(name).next(),
+))
def _key(value):
return value['name']
installed.sort(key=_key)
+pi = PackageIndex()
+
upgrade = False
for info in installed:
print(Checking for new version of %s. % info['name'])
@@ -46,7 +52,8 @@
def help():
-print(Use this script via ./bin/zopepy inst/checknew.py.)
+print(Use this script via ./bin/allpy inst/checknew.py.)
+print(You need to use the alltests.cfg config file for buildout.)
if __name__ == '__main__':
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/ Another round of package updates. These are no direct Zope2 dependencies, but required to run all tests of all direct dependencies
Log message for revision 101377: Another round of package updates. These are no direct Zope2 dependencies, but required to run all tests of all direct dependencies Changed: U Zope/trunk/doc/CHANGES.rst U Zope/trunk/versions.cfg -=- Modified: Zope/trunk/doc/CHANGES.rst === --- Zope/trunk/doc/CHANGES.rst 2009-07-01 17:24:10 UTC (rev 101376) +++ Zope/trunk/doc/CHANGES.rst 2009-07-01 17:32:39 UTC (rev 101377) @@ -24,15 +24,20 @@ - Updated packages: - pytz = 2009j + - zc.buildout = 1.3.0 - zope.app.appsetup = 3.12.0 - zope.app.cache = 3.6.0 - zope.app.pagetemplate = 3.7.1 - zope.app.publication = 3.8.1 - zope.app.publisher = 3.8.3 - zope.app.testing = 3.7.0 + - zope.app.wsgi = 3.6.0 + - zope.app.zcmlfiles = 3.5.5 - zope.contenttype = 3.4.2 - zope.dublincore = 3.4.3 - zope.i18nmessageid = 3.5.0 + - zope.index = 3.5.2 + - zope.interface = 3.5.2 - zope.server = 3.6.0 - zope.testing = 3.7.5 - zope.traversing = 3.7.1 Modified: Zope/trunk/versions.cfg === --- Zope/trunk/versions.cfg 2009-07-01 17:24:10 UTC (rev 101376) +++ Zope/trunk/versions.cfg 2009-07-01 17:32:39 UTC (rev 101377) @@ -20,7 +20,7 @@ pytz = 2009j setuptools = 0.6c9 transaction = 1.0a1 -zc.buildout = 1.2.1 +zc.buildout = 1.3.0 zc.lockfile = 1.0.0 zc.recipe.egg = 1.2.2 zc.recipe.testrunner = 1.2.0 @@ -59,8 +59,8 @@ zope.app.securitypolicy = 3.5.1 zope.app.session = 3.6.0 zope.app.testing = 3.7.0 -zope.app.wsgi = 3.5.2 -zope.app.zcmlfiles = 3.5.3 +zope.app.wsgi = 3.6.0 +zope.app.zcmlfiles = 3.5.5 zope.app.zopeappgenerations = 3.5.0 zope.app.zptpage = 3.5.0 zope.authentication = 3.7.0 @@ -91,8 +91,8 @@ zope.hookable = 3.4.1 zope.i18n = 3.7.0 zope.i18nmessageid = 3.5.0 -zope.index = 3.5.1 -zope.interface = 3.5.1 +zope.index = 3.5.2 +zope.interface = 3.5.2 zope.intid = 3.7.0 zope.keyreference = 3.6.1 zope.lifecycleevent = 3.5.2 ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] Making PersistentList satisfy zope.schema.List
Hello, I think then it's the widgets bad behavour. It should do a ``newValue = previousValue.__class__(newItems)`` instead of a dumb ``newValue = list(newItems)`` (Where available of course) The problem is when the previousValue is None so we can't determine the the type. Tuesday, June 30, 2009, 11:04:49 PM, you wrote: RI I think it's different. If you use a zope.schem.List field RI the widgets will store the list at once. This whould replace RI the initial created PeristentList. (or not?) RI In general if you store a simple list as attribute on a RI persistent class it's fine, everything is stored. RI If you like to append or pop from this list, then yes, you RI will need a PersistentList otherwise the changes in the RI list are not stored back to the DB. (right?) RI Fazit, RI the zope.schema.List field and the Sequence widget RI is not compatible with initial PersitentList beause RI the widget will probably replace the list with a RI simple list. RI Note, I'm not 100% sure if I'm correct. But it is at RI least something which we have to make sure that this RI is working. -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: If you risk nothing, then you risk everything. - Geena Davis ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to test changes to ZTK packages?
On Wed, Jul 1, 2009 at 7:08 AM, Wolfgang Schnerringw...@gocept.com wrote: I think it would be useful to standardize on *one* compatibility testing method for the ZTK (and then document it). I think it would be good if someone actually would define what the ZTK includes in terms of packages ;) zope.release currently defines some megalomanic set of all zope, z3c and bunch of other things. Some of the z3c packages require lxml which has been seen as a bit tedious to deal with. I don't know when all tests for all packages in zope.release have passed last, but I suspect that has been quite a while for its current trunk. I can still offer http://svn.zope.org/Zope/trunk/versions.cfg?view=markup as a base for a technical definition. That list uses all the latest versions of all packages available on PyPi and I keep it updated for now, as there's no other place where I could get a current ZTK KGS definition from. It includes all packages that are required by Zope2 to both run it and run all of its tests including all tests for all transitive dependencies. Cheers, Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to test changes to ZTK packages?
On Jun 30, 2009, at 2:41 PM, Tres Seaver wrote:
...
IMO, Any ZTK package should be testable via plain 'python2.{5,6}
setup.py test'. If that doesn't get the testing dependencies
installed,
then they should be added.
There is a recipe for testing *other* packages which might be affected
by changes to the package-under-development:
http://pypi.python.org/pypi/z3c.recipe.compattest
I don't know how to supply the set of dependents to that recipe
(something in the buildout config file, I guess).
Thanks, I missed this yesterday. Just noticed it when I saw the replies.
Jim
--
Jim Fulton
Zope Corporation
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to test changes to ZTK packages?
On Jul 1, 2009, at 1:08 AM, Wolfgang Schnerring wrote: * Tres Seaver tsea...@palladion.com [2009-06-30 20:41]: Jim Fulton wrote: I should know this, but I don't. What is the recommended way to test changes to core ZTK packages to mitigate the risk that changes affect other packages? Is there a page somewhere with instructions? I tried using using zope.release. Building the trunk of zope.release with Python 2.4 and running the tests gives lots of test import errors and test failures. (Lots of tests want to import z3c.pt.) The tests hang when I try to build and run with Python 2.6. There is a recipe for testing *other* packages which might be affected by changes to the package-under-development: http://pypi.python.org/pypi/z3c.recipe.compattest This recipe was written at the Grok dependency-cleanup sprint in January with exactly the purpose Jim talks about: testing packages against each other to make sure changes in one don't adversely affect the others. I haven't studied zope.release closely yet, but I think testing-wise it does quite a similar thing, namely running tests for a set of packages. The difference is that compattest uses either pinned version from buildout (but doesn't supply its own list of pins), or alternatively trunk checkouts. Also, it seems to be more lightweight than zope.release both in concept and in usage (mostly since it only does one thing, namely running tests, and not other release management stuff like creating tarballs and uploading them etc.), but I'm biased since I'm one of the compattest authors. For the record, the usage is 1. add it to your buildout, minimally like so: [compattest] recipe = z3c.recipe.compattest 2. run bin/compattest 3. there is no step three. ;-) I don't know how to supply the set of dependents to that recipe (something in the buildout config file, I guess). You can specify include and exclude options; the default is to include a list of zope.* packages that we pulled out of thin air at the sprint, it'd probably be better to use the KGS as a default instead -- but that would duplicate even more zope.release functionality. Where is this list? In the recipe? I think it would be useful to standardize on *one* compatibility testing method for the ZTK (and then document it). Yes. My instinct would be to separate KGS handling from tarball creation from testing, that is, remove the test-business from zope.release and use the compattest recipe instead. (Alternatively, retire compattest and have zope.release gain the ability to use trunks so it could be used for continuous integration purposes as well -- but that doesn't feel quite right, to be honest) Thoughts? I agree we need one way to do this. I think the KGS concept is right. I think there should be a known good configuration of packages and a way to evolve it. The configuration should be changed only after testing changes. The configuration needs to include Python versions that it is tested with. Beyond that, I don't care what the process is as long as it is documented. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to test changes to ZTK packages?
On Jul 1, 2009, at 1:08 AM, Wolfgang Schnerring wrote: * Tres Seaver tsea...@palladion.com [2009-06-30 20:41]: Jim Fulton wrote: I should know this, but I don't. What is the recommended way to test changes to core ZTK packages to mitigate the risk that changes affect other packages? Is there a page somewhere with instructions? I tried using using zope.release. Building the trunk of zope.release with Python 2.4 and running the tests gives lots of test import errors and test failures. (Lots of tests want to import z3c.pt.) The tests hang when I try to build and run with Python 2.6. There is a recipe for testing *other* packages which might be affected by changes to the package-under-development: http://pypi.python.org/pypi/z3c.recipe.compattest This recipe was written at the Grok dependency-cleanup sprint in January with exactly the purpose Jim talks about: testing packages against each other to make sure changes in one don't adversely affect the others. I haven't studied zope.release closely yet, but I think testing-wise it does quite a similar thing, namely running tests for a set of packages. The difference is that compattest uses either pinned version from buildout (but doesn't supply its own list of pins), or alternatively trunk checkouts. So it provides no good configuration to test against. This is a fatal flaw IMO. Also, it seems to be more lightweight than zope.release both in concept and in usage (mostly since it only does one thing, namely running tests, and not other release management stuff like creating tarballs and uploading them etc.), but I'm biased since I'm one of the compattest authors. For the record, the usage is 1. add it to your buildout, minimally like so: [compattest] recipe = z3c.recipe.compattest 2. run bin/compattest 3. there is no step three. ;-) I tried this with the current trunk of zope.app.publisher, which I'm about to modify. I added a compattest part: [compattest] recipe = z3c.recipe.compattest I didn't get bin/compattest, but I did get bin/test_compattest. When I run this, I get lots and lots of errors. :( I could attach them, but what's the point? I don't know how to supply the set of dependents to that recipe (something in the buildout config file, I guess). You can specify include and exclude options; the default is to include a list of zope.* packages that we pulled out of thin air at the sprint, it'd probably be better to use the KGS as a default instead -- but that would duplicate even more zope.release functionality. I think it would be useful to standardize on *one* compatibility testing method for the ZTK (and then document it). My instinct would be to separate KGS handling from tarball creation from testing, that is, remove the test-business from zope.release and use the compattest recipe instead. (Alternatively, retire compattest and have zope.release gain the ability to use trunks so it could be used for continuous integration purposes as well -- but that doesn't feel quite right, to be honest) Thoughts? I'm kind of stuck at this point. The KGS approach seems most promising because it is based on the idea of a known working configuration. It is still baffling to me that people checked version numbers into the trunk of zope.release that don't pass tests. (Many of the packages there don't even run their tests.) Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to test changes to ZTK packages?
On Jun 30, 2009, at 7:25 PM, Stephan Richter wrote: Given that this locks down versions, wouldn't it make more sense to not check in configurations with failing (or hanging) tests? That's probably not a bad idea. I think we should make that a rule. So, I wonder if there is a previous revision of the trunk for which the tests pass for some version of Python. I guess I'll try to discover that. It's a bit mysterious that there are packages for which tests don't even run. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to test changes to ZTK packages?
Wichert Akkerman wrote: On 6/30/09 7:03 PM, Stephan Richter wrote: It is needed for the latest-versions script as this parses XML. I consider lxml pretty much the standard tool to do XML in Python these days. Who is not using lxml? I suspect the majority of people who use OSX as their main platform try to stay as far away from lxml as possible. Not because lxml is bad, but because unless you use special magic it will make your python randomly segfault. This is very sad, and it is not lxml's fault but I see no good solution at this moment. There is a good solution: binary eggs. lxml already does this for Windows, and we're about to get them for OS X. So I think lxml will again become a reasonable thing to depend on. Which is important, because it's a very good library. Using z3c.recipe.staticlxml recipe helps a bit for people using buildout, but that is not everyone and even then I have seen random segfaults. I've never seen errors with a static build (although I've seen the recipe fail to remove a non-static egg in a shared eggs cache). Maybe I'm lucky. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to test changes to ZTK packages?
On Jun 30, 2009, at 10:14 AM, Stephan Richter wrote: On Tuesday 30 June 2009, Jim Fulton wrote: I should know this, but I don't. What is the recommended way to test changes to core ZTK packages to mitigate the risk that changes affect other packages? Is there a page somewhere with instructions? I tried using using zope.release. Building the trunk of zope.release with Python 2.4 and running the tests gives lots of test import errors and test failures. (Lots of tests want to import z3c.pt.) The tests hang when I try to build and run with Python 2.6. Yes, I think testing with zope.release is a good way of doing this right now. What is the difference between zope.release and zope.kgs? Is the latter a fossil? Does it need to go away? Why does zope.release have a 2-step build process? Perhaps naively, it seems that one could define a simple project that defined a test script over a known good set of projects. Is the 2-step process a consequence of maintaining the index or tar ball? (I'm not criticizing, I'm just trying to understand.) Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.interface 3.5.2 release
I just released zope.interface 3.5.2, which adds only this bug fix: - BaseAdapterRegistry.unregister, unsubscribe: Remove empty portions of the data structures when something is removed. This avoids leaving references to global objects (interfaces) that may be slated for removal from the calling application. I've made a source distribution available via PyPI: http://pypi.python.org/pypi/zope.interface/ Windows users would likely be thankful if someone with the appropriate tools and know-how to build Windows binary distributions were to do so and upload those to PyPI as well. Enjoy! -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface 3.5.2 release
On Wed, Jul 1, 2009 at 6:01 PM, Fred Drakefdr...@gmail.com wrote: I've made a source distribution available via PyPI: http://pypi.python.org/pypi/zope.interface/ Windows users would likely be thankful if someone with the appropriate tools and know-how to build Windows binary distributions were to do so and upload those to PyPI as well. Just did that for Python 2.4 to 2.6. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface 3.5.2 release
On Wed, Jul 1, 2009 at 12:30 PM, Hanno Schlichtingha...@hannosch.eu wrote: Just did that for Python 2.4 to 2.6. Thanks, Hanno! -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to test changes to ZTK packages?
On Jul 1, 2009, at 1:42 PM, Stephan Richter wrote: On Wednesday 01 July 2009, Jim Fulton wrote: What is the difference between zope.release and zope.kgs? Is the latter a fossil? Does it need to go away? zope.kgs is the software and zope.release is the management of the Zope 3 KGS. So a Grok KGS would use zope.kgs but not zope.release. Why does zope.release have a 2-step build process? Perhaps naively, it seems that one could define a simple project that defined a test script over a known good set of projects. Is the 2-step process a consequence of maintaining the index or tar ball? (I'm not criticizing, I'm just trying to understand.) I have been bothered by this before, but not enough to fix it. Basically, It could easily be one step. The two steps stem from the fact that you have a KGS file from which you produce all sorts of interesting artifacts. The test setup is one such artifact. you then use the artifact. Of course, for convenience one step would be fine. Maybe it is even a PITA in zope.release. OK, well, I'll try to sort this out using zope.release. Wish me luck. :) Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] psycopg import error
Hi,
I also experienced the problem this morning when trying to use the product
ZPsycopgDA version 2.0.11 on Zope. The error reported by Plone/Zope is:
Error Value: psycopg version mismatch (imported 2.0.11 (dt dec ext pq3))
Due to the fact it is extracting the first 5 characters (2.0.1) and comparing
it to the full version (2.0.11), thus failing.
Instead of changing the index to 6 (which would then break 2.0.8 versions,
etc.), you can explode the string by spaces, then extract the first part:
so the only change would be to line 119 of DA.py, from:
if psycopg2.__version__[:5] not in ALLOWED_PSYCOPG_VERSIONS:
to:
if psycopg2.__version__.split(' ')[0] not in ALLOWED_PSYCOPG_VERSIONS:
No other changes to the versions definition would be required.
This will be both backwards and forwards compatible with all versions from
0.0.0 to 999.999.999 (well, infinity really)!
Keep up the good work.
Cheers,
Tom
--
Thomas O'Connor
Web developer
(02) 498 54130
thomas.ocon...@newcastle.edu.au
Office of IT Services
Bar on the Hill Building
UoN Services Limited
University Drive
Callaghan NSW 2308
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
