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-dev] How to test changes to ZTK packages?
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. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ 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 Schlichting wrote: > Just did that for Python 2.4 to 2.6. Thanks, Hanno! -Fred -- Fred L. Drake, Jr. "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 Drake 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 )
[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. "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 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 )
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 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?
On Jul 1, 2009, at 1:08 AM, Wolfgang Schnerring wrote: > * Tres Seaver [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 Jul 1, 2009, at 1:08 AM, Wolfgang Schnerring wrote: > * Tres Seaver [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 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 Wed, Jul 1, 2009 at 7:08 AM, Wolfgang Schnerring 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] 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 )
