Re: [Zope-dev] [Checkins] SVN: z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py Don't import site on initialization, as this mitigates the buildout 1.5 way of setting sys.path
Hi, currently the ZTK tests on the trunk do not run successfully in a virtualenv. The errors look like: atom:trunk mac$ bin/test-ztk Running test-ztk-zope.securitypolicy test-ztk-zope.securitypolicy failed with: Traceback (most recent call last): File "/Users/mac/Documents/tmp/zopetoolkit/trunk/bin/test-ztk-zope.securitypolicy", line 35, in <module> import zope.testrunner File "/Users/mac/Documents/eggs/zope.securitypolicy-3.7.0-py2.5.egg/zope/__init__.py", line 1, in <module> __import__('pkg_resources').declare_namespace(__name__) File "/Users/mac/Documents/eggs/distribute-0.6.14-py2.5.egg/pkg_resources.py", line 17, in <module> from urlparse import urlparse, urlunparse ImportError: No module named urlparse ... When I revert the following change, only the test for zope.testing fails (and all zope.app-tests pass): Am 06.10.2010 um 08:40 schrieb Jan-Jaap Driessen:
Log message for revision 117268: Don't import site on initialization, as this mitigates the buildout 1.5 way of setting sys.path
Changed: U z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py
-=- Modified: z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py =================================================================== --- z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py 2010-10-06 06:30:44 UTC (rev 117267) +++ z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py 2010-10-06 06:40:43 UTC (rev 117268) @@ -31,7 +31,7 @@ def start(self): self.start = time.time() self.process = subprocess.Popen( - [sys.executable, self.script, '--exit-with-status'] + self.args, + [sys.executable, '-S', self.script, '--exit-with-status'] + self.args, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
But reverting this change does not help to get the tests of z3c.recipe.compattest itself running again. There are the same errors like before. Is it intensional that ZTK tests fail in virtualenv? What needs be done to get the tests running again in virtualenv? Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
On 11/26/10 8:37 AM, Michael Howitz wrote:
currently the ZTK tests on the trunk do not run successfully in a virtualenv. <sip> But reverting this change does not help to get the tests of z3c.recipe.compattest itself running again. There are the same errors like before.
Is it intensional that ZTK tests fail in virtualenv? What needs be done to get the tests running again in virtualenv?
I don't think this was intentional. Then again, I guess it __was__ the intention to make use of the system-python-path-isolation-features in zc.buildout. Personally, I'm not sure where to start fixing this, help and insights appreciated... regards, jw
On 11/26/10 10:49 AM, Jan-Wijbrand Kolman wrote:
On 11/26/10 8:37 AM, Michael Howitz wrote:
currently the ZTK tests on the trunk do not run successfully in a virtualenv. <sip> But reverting this change does not help to get the tests of z3c.recipe.compattest itself running again. There are the same errors like before.
Is it intensional that ZTK tests fail in virtualenv? What needs be done to get the tests running again in virtualenv?
I don't think this was intentional. Then again, I guess it __was__ the intention to make use of the system-python-path-isolation-features in zc.buildout. Personally, I'm not sure where to start fixing this, help and insights appreciated...
Hmmm, maybe this has been completely obvious to others, but I guess it really boils down to: https://bugs.launchpad.net/virtualenv/+bug/572545 where -S is broken in virtualenvs. Grok's grokproject tool has exactly the same problems, where it doesn't work anymore in a virtualenv *and* we're using -S when calling a newly created project's bootstrap.py. regards,jw
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/26/2010 04:49 AM, Jan-Wijbrand Kolman wrote:
On 11/26/10 8:37 AM, Michael Howitz wrote:
currently the ZTK tests on the trunk do not run successfully in a virtualenv. <sip> But reverting this change does not help to get the tests of z3c.recipe.compattest itself running again. There are the same errors like before.
Is it intensional that ZTK tests fail in virtualenv? What needs be done to get the tests running again in virtualenv?
I don't think this was intentional. Then again, I guess it __was__ the intention to make use of the system-python-path-isolation-features in zc.buildout. Personally, I'm not sure where to start fixing this, help and insights appreciated...
I'd rather shoot the system-python-with-isolation features in the head, myself. Anybody *developing* ZTK should be willing and able to set up either an alternative Python installation or a virtualenv. FWIW, I'm not using zc.buildout >= 1.5.0devel anywhere because of the breakage it induces in my normal workflow. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzv14MACgkQ+gerLs4ltQ7KmACeMi+Dza/VQ0J3d5vi77Dahp4I LYYAoK9nP1WlERGGq4dSRllS40QD9Hiv =RIRM -----END PGP SIGNATURE-----
Hi Michael, On 26 November 2010 08:37, Michael Howitz <mh@gocept.com> wrote:
Hi,
currently the ZTK tests on the trunk do not run successfully in a virtualenv.
The errors look like:
atom:trunk mac$ bin/test-ztk Running test-ztk-zope.securitypolicy test-ztk-zope.securitypolicy failed with: Traceback (most recent call last): File "/Users/mac/Documents/tmp/zopetoolkit/trunk/bin/test-ztk-zope.securitypolicy", line 35, in <module> import zope.testrunner File "/Users/mac/Documents/eggs/zope.securitypolicy-3.7.0-py2.5.egg/zope/__init__.py", line 1, in <module> __import__('pkg_resources').declare_namespace(__name__) File "/Users/mac/Documents/eggs/distribute-0.6.14-py2.5.egg/pkg_resources.py", line 17, in <module> from urlparse import urlparse, urlunparse ImportError: No module named urlparse ...
When I revert the following change, only the test for zope.testing fails (and all zope.app-tests pass):
Am 06.10.2010 um 08:40 schrieb Jan-Jaap Driessen:
Log message for revision 117268: Don't import site on initialization, as this mitigates the buildout 1.5 way of setting sys.path
Changed: U z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py
-=- Modified: z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py =================================================================== --- z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py 2010-10-06 06:30:44 UTC (rev 117267) +++ z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py 2010-10-06 06:40:43 UTC (rev 117268) @@ -31,7 +31,7 @@ def start(self): self.start = time.time() self.process = subprocess.Popen( - [sys.executable, self.script, '--exit-with-status'] + self.args, + [sys.executable, '-S', self.script, '--exit-with-status'] + self.args, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
But reverting this change does not help to get the tests of z3c.recipe.compattest itself running again. There are the same errors like before.
Is it intensional that ZTK tests fail in virtualenv? What needs be done to get the tests running again in virtualenv?
It took a while for me to react to your email, my apologies. I remember now that I added the '-S' to z3c.recipe.compattest in order to make compattest run on windows machines. It was not my intention to break running from inside a virtualenv. I'll look into the issue some more this week. Kind regards, -- Jan-Jaap Driessen
Hi Michael, On 12 December 2010 21:49, Jan-Jaap Driessen <jdriessen@thehealthagency.com> wrote:
Hi Michael,
On 26 November 2010 08:37, Michael Howitz <mh@gocept.com> wrote:
Hi,
currently the ZTK tests on the trunk do not run successfully in a virtualenv.
The errors look like:
atom:trunk mac$ bin/test-ztk Running test-ztk-zope.securitypolicy test-ztk-zope.securitypolicy failed with: Traceback (most recent call last): File "/Users/mac/Documents/tmp/zopetoolkit/trunk/bin/test-ztk-zope.securitypolicy", line 35, in <module> import zope.testrunner File "/Users/mac/Documents/eggs/zope.securitypolicy-3.7.0-py2.5.egg/zope/__init__.py", line 1, in <module> __import__('pkg_resources').declare_namespace(__name__) File "/Users/mac/Documents/eggs/distribute-0.6.14-py2.5.egg/pkg_resources.py", line 17, in <module> from urlparse import urlparse, urlunparse ImportError: No module named urlparse ...
When I revert the following change, only the test for zope.testing fails (and all zope.app-tests pass):
Am 06.10.2010 um 08:40 schrieb Jan-Jaap Driessen:
Log message for revision 117268: Don't import site on initialization, as this mitigates the buildout 1.5 way of setting sys.path
Changed: U z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py
-=- Modified: z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py =================================================================== --- z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py 2010-10-06 06:30:44 UTC (rev 117267) +++ z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py 2010-10-06 06:40:43 UTC (rev 117268) @@ -31,7 +31,7 @@ def start(self): self.start = time.time() self.process = subprocess.Popen( - [sys.executable, self.script, '--exit-with-status'] + self.args, + [sys.executable, '-S', self.script, '--exit-with-status'] + self.args, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.STDOUT,
But reverting this change does not help to get the tests of z3c.recipe.compattest itself running again. There are the same errors like before.
Is it intensional that ZTK tests fail in virtualenv? What needs be done to get the tests running again in virtualenv?
It took a while for me to react to your email, my apologies. I remember now that I added the '-S' to z3c.recipe.compattest in order to make compattest run on windows machines. It was not my intention to break running from inside a virtualenv. I'll look into the issue some more this week.
It looks like this patch to z3c.recipe.compattest fixes the virtualenv issue: http://pastie.org/1374124 With this patch I successfully ran the ZTK trunk tests on Windows and OSX machines inside and outside a virtualenv. If nobody objects, I'll release this as z3c.recipe.compattest 0.13.1. -- Jan-Jaap Driessen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/13/2010 04:09 PM, Jan-Jaap Driessen wrote:
It looks like this patch to z3c.recipe.compattest fixes the virtualenv issue:
With this patch I successfully ran the ZTK trunk tests on Windows and OSX machines inside and outside a virtualenv.
If nobody objects, I'll release this as z3c.recipe.compattest 0.13.1.
+1 from me. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0GjUcACgkQ+gerLs4ltQ66KACgjg7ZtOiS+/t9mm67T7hckJwa RT8AoNQbsK6tEbJM/neUrlsZy513Dwj8 =Wi0R -----END PGP SIGNATURE-----
On 13 December 2010 22:16, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/13/2010 04:09 PM, Jan-Jaap Driessen wrote:
It looks like this patch to z3c.recipe.compattest fixes the virtualenv issue:
With this patch I successfully ran the ZTK trunk tests on Windows and OSX machines inside and outside a virtualenv.
If nobody objects, I'll release this as z3c.recipe.compattest 0.13.1.
+1 from me.
Tres. - --
I released z3c.recipe.compattest 0.13.1 which on my machines runs the ZTK tests without problems in the following configurations: win32 + sys python win32 + virtualenv python win32 + virtualenv-no-site-packages python osx + sys python osx + virtualenv python osx + virtualenv-no-site-packages python ubuntu + sys python ubuntu + virtualenv python ubuntu + virtualenv-no-site-packages python Also, last night the THA buildbot ran the ZTK trunk tests with the trunk of z3c.recipe.compattest without problems. Michael, does 0.13.1 fix your problem? Cheers, -- Jan-Jaap Driessen
Am 17.12.2010 um 13:09 schrieb Jan-Jaap Driessen:
I released z3c.recipe.compattest 0.13.1 which on my machines runs the ZTK tests without problems in the following configurations:
win32 + sys python win32 + virtualenv python win32 + virtualenv-no-site-packages python
osx + sys python osx + virtualenv python osx + virtualenv-no-site-packages python
ubuntu + sys python ubuntu + virtualenv python ubuntu + virtualenv-no-site-packages python
Also, last night the THA buildbot ran the ZTK trunk tests with the trunk of z3c.recipe.compattest without problems.
Michael, does 0.13.1 fix your problem?
Thank you very much for your investigation. 0.13.1 works for me: I can run its tests and the ZTK tests, too. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
participants (4)
-
Jan-Jaap Driessen -
Jan-Wijbrand Kolman -
Michael Howitz -
Tres Seaver