Re: [Zope-dev] How to test changes to ZTK packages?
Hi, On 07/01/2009 11:12 AM, Jim Fulton wrote: [...] 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? The recipe takes two arguments: - a list of regular expressions to describe packages that should be included - a list of regular expressions to describe packages that should be excluded There is currently a builtin list for each of them that gets appended to the ones you specify when using the recipe in your buildout. 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. The compattest is intended to check the trunks of packages located in one repository like svn.zope.org against the development version of the package you're working on so you can see whether your changes will cause others that depend on you to break. I think it's one of the issues we need to solve in our process and it was actually very valuable when doing the large dependency refactoring at the sprint. If you have a multi-core machine, you can also ask it to run the various test runners in parallel. I was able to execute the 100+ package tests in less than 10 minutes on an 8-core machine. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 Tue, 2009-06-30 at 14:35 -0400, Tres Seaver wrote: While I know that Mac people often report problems building lxml, I never have issues building lxml on Linux: the '--static-deps' option is a sufficient workaround for variants with too-old versions of libxml2 / libxslt. I do not know what platform you are running but I have had my share of frustrations with lxml on Fedora and Ubuntu on x86_64. --Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** signature.asc Description: This is a digitally signed message part ___ 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Cook wrote: On Tue, 2009-06-30 at 14:35 -0400, Tres Seaver wrote: While I know that Mac people often report problems building lxml, I never have issues building lxml on Linux: the '--static-deps' option is a sufficient workaround for variants with too-old versions of libxml2 / libxslt. I do not know what platform you are running but I have had my share of frustrations with lxml on Fedora and Ubuntu on x86_64. I haven't had issues with lxml on 32- or 64-bit versions of either Fedora or Ubuntu any time within the last eighteen months or so. I just easy_installed it into a fresh virtualenv on Ubuntu x86_64: $ gunzip -c /usr/share/doc/ubuntu-standard/changelog.gz | head -1 ubuntu-meta (1.124) intrepid; urgency=low $ uname -a Linux mred 2.6.27-14-generic #1 SMP Wed Apr 15 19:29:46 UTC 2009 \ x86_64 GNU/Linux $ /opt/Python-2.6.2/bin/virtualenv --no-site-packages /tmp/lxml ... $ /tmp/lxml/bin/easy_install lxml Searching for lxml Reading http://pypi.python.org/simple/lxml/ Reading http://codespeak.net/lxml Best match: lxml 2.2.2 Downloading http://codespeak.net/lxml/lxml-2.2.2.tgz Processing lxml-2.2.2.tgz Running lxml-2.2.2/setup.py -q bdist_egg --dist-dir \ /tmp/easy_install-Gyfz1B/lxml-2.2.2/egg-dist-tmp-xMuOwQ Building lxml version 2.2.2. NOTE: Trying to build without Cython, pre-generated \ 'src/lxml/lxml.etree.c' needs to be available. Using build configuration of libxslt 1.1.24 Building against libxml2/libxslt in the following directory: /usr/lib Adding lxml 2.2.2 to easy-install.pth file Installed \ /tmp/lxml/lib/python2.6/site-packages/lxml-2.2.2-py2.6-linux-x86_64.egg Processing dependencies for lxml Finished processing dependencies for lxml Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKUOk8+gerLs4ltQ4RAguOAJ4qj5NuKwV3K5K8HMU8lFBFkmBIlQCZAaWO uZ3Zqj0rtXmZpSYp4/cDJ58= =Slt4 -END PGP SIGNATURE- ___ 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 )
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 )
[Zope-dev] How to test changes to ZTK packages?
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. BTW, zope.release wants lxml, which is a real pain on Mac OS X and Centos 4. Does the ZTK really need to depend on lxml? 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?
I have to chime in here too lxml is a real pain and seems to be problematic to get a straightforward build for packages other than ZTK as well. I have had varying success building lxml even under ubuntu - success seems to be dependant on the type of build defined. T On Tue, Jun 30, 2009 at 6:28 PM, Jim Fulton j...@zope.com 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. BTW, zope.release wants lxml, which is a real pain on Mac OS X and Centos 4. Does the ZTK really need to depend on lxml? 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 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 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. I tried to verify the steps: 1. Checkout zope.release 2. Run python bootstrap.py 3. Run ./bin/buildout -N 4. Run ./bin/generate-buildout 5. cd test 6. python ../bootstrap.py 7. ./bin/buildout -N 8. ./bin/test -vpc1 I am running the tests as I am writing this. So far I got one failure: Traceback (most recent call last): File /opt/zope/packages/eggs/z3c.macro-1.2.1-py2.5.egg/z3c/macro/tests.py, line 29, in module import z3c.pt ImportError: No module named pt I'll report the full output when it is done. BTW, zope.release wants lxml, which is a real pain on Mac OS X and Centos 4. Does the ZTK really need to depend on lxml? 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? Having said that, latest-versions is not needed by everyone all the time. I could live with putting it into an extra and not build the latest-versions script by default. 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] How to test changes to ZTK packages?
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. 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. Wichert. ___ 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 1:03 PM, Stephan Richter wrote: I consider lxml pretty much the standard tool to do XML in Python these days. I don't want to diss lxml, but since it's not in the standard library, I imagine far more people use element tree. Who is not using lxml? I don't. I don't do much with xml. If I did, I might use it more. I see no reason for a web framework to be all tied up with xml. I wouldn't mind lxml if it wasn't so hard to install. Having said that, latest-versions is not needed by everyone all the time. I could live with putting it into an extra and not build the latest- versions script by default. +1 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 1:03 PM, Stephan Richter wrote: ... 2. Run python bootstrap.py Which Python? 2.4, 2.5, 2.6? All of the above? 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?
Can't use lxml on google app engine either. I use ElementTree. If only the lxml extensions to the etree API were available in ElementTree, especially the ability to pretty print the xml and do xpath queries, that would be great. On Tue, Jun 30, 2009 at 7:25 PM, Jim Fultonj...@zope.com wrote: On Jun 30, 2009, at 1:03 PM, Stephan Richter wrote: I consider lxml pretty much the standard tool to do XML in Python these days. I don't want to diss lxml, but since it's not in the standard library, I imagine far more people use element tree. Who is not using lxml? I don't. I don't do much with xml. If I did, I might use it more. I see no reason for a web framework to be all tied up with xml. I wouldn't mind lxml if it wasn't so hard to install. Having said that, latest-versions is not needed by everyone all the time. I could live with putting it into an extra and not build the latest- versions script by default. +1 Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - zope-...@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 ) -- Paul Carduner http://www.carduner.net ___ 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 Tuesday 30 June 2009, Jim Fulton wrote: On Jun 30, 2009, at 1:03 PM, Stephan Richter wrote: ... 2. Run python bootstrap.py Which Python? 2.4, 2.5, 2.6? All of the above? I have mainly run test under 2.5. I am fine if people run those tests after changes in any Python version. ;-) Of course, if you want to be super-diligent, I think both Python 2.5 and 2.6 should be tested. 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] How to test changes to ZTK packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Hoffman wrote: I have to chime in here too lxml is a real pain and seems to be problematic to get a straightforward build for packages other than ZTK as well. I have had varying success building lxml even under ubuntu - success seems to be dependant on the type of build defined. While I know that Mac people often report problems building lxml, I never have issues building lxml on Linux: the '--static-deps' option is a sufficient workaround for variants with too-old versions of libxml2 / libxslt. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKSlrV+gerLs4ltQ4RAryqAKCVy3gazZEqD8Vm23B79HCTRGDZFgCaAyfe W8I7h3fmNafq6lQOjV3GZ8c= =QLYw -END PGP SIGNATURE- ___ 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 1:03 PM, Stephan Richter wrote: ... I am running the tests as I am writing this. So far I got one failure: Traceback (most recent call last): File /opt/zope/packages/eggs/z3c.macro-1.2.1-py2.5.egg/z3c/macro/ tests.py, line 29, in module import z3c.pt ImportError: No module named pt I'll report the full output when it is done. Any news? Or did it hang? (It hangs for me with Pythonj 2.6.) 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 1:04 PM, Stephan Richter wrote: On Tuesday 30 June 2009, Stephan Richter wrote: I'll report the full output when it is done. And here it is. OK, this sorta looks like what I got with Python 2.4. It probably would have been good enough to say yeah, I get lots of errors too. :) So basically, this *is* how we're supposed to run tests and we're in bad shape, Given that this locks down versions, wouldn't it make more sense to not check in configurations with failing (or hanging) 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 Tuesday 30 June 2009, Jim Fulton wrote: And here it is. OK, this sorta looks like what I got with Python 2.4. It probably would have been good enough to say yeah, I get lots of errors too. :) Sorry! ;-) So basically, this is how we're supposed to run tests and we're in bad shape, Yes. 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. 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] How to test changes to ZTK packages?
* 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. 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? Wolfgang ___ 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 )
