[lxml-dev] lxml 0.8 on windows fails tests
Hi, I have lxml 0.8 compiled with the latest windows binaries from http://xmlsoft.org/sources/win32/ python selftest.py passes, but python test.py fails oddly. E:\prj\src\lxml-0.8>python test.py Traceback (most recent call last): File "test.py", line 591, in ? exitcode = main(sys.argv) File "test.py", line 554, in main test_cases = get_test_cases(test_files, cfg, tracer=tracer) File "test.py", line 254, in get_test_cases module = import_module(file, cfg, tracer=tracer) File "test.py", line 197, in import_module mod = __import__(modname) File "E:\prj\src\lxml-0.8\src\lxml\tests\test_errors.py", line 9, in ? from lxml import etree ImportError: cannot import name etree But if I run by hand, it works: E:\prj\src\lxml-0.8>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
from lxml import etree ^Z
Is it possible that test.py is doing something with the pythonpath that might contribute to this oddness? -- My site-packages/lxml directory looks like this: Directory of D:\Python24\Lib\site-packages\lxml 11/19/2005 04:37 PM <DIR> . 11/19/2005 04:37 PM <DIR> .. 11/19/2005 04:30 PM 163,840 etree.pyd 10/25/2003 01:31 PM 888,832 iconv.dll 05/03/2005 08:37 PM 102,400 libexslt.dll 08/06/2005 04:22 PM 898,560 libxml2.dll 05/03/2005 08:37 PM 282,624 libxslt.dll 11/19/2005 04:34 PM <DIR> tests 08/06/2005 04:15 PM 73,728 zlib1.dll 07/07/2005 08:04 AM 5,956 _elementpath.py 11/19/2005 04:34 PM 3,591 _elementpath.pyc 07/07/2005 08:04 AM 21 __init__.py 11/19/2005 04:34 PM 126 __init__.pyc I would suspect a .dll load dependency problem, but PATH and CWD is the same in both cases, so .. stumper. -- Also, and this could be a clueless question, could lxml build off the python libxlm binary package on windows, so that I wouldn't have two copies of libxml2.dll and friends kicking around.. ? I suppose not, since Pyrex would be "upcalling" to the python interface exposed by the libxml python bindings.. I guess libxml directly calls libxml C interface.. ? -- Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com AOL-IM or SKYPE: BKClements
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brad Clements wrote:
Hi,
I have lxml 0.8 compiled with the latest windows binaries from
http://xmlsoft.org/sources/win32/
python selftest.py passes, but python test.py fails oddly.
E:\prj\src\lxml-0.8>python test.py Traceback (most recent call last): File "test.py", line 591, in ? exitcode = main(sys.argv) File "test.py", line 554, in main test_cases = get_test_cases(test_files, cfg, tracer=tracer) File "test.py", line 254, in get_test_cases module = import_module(file, cfg, tracer=tracer) File "test.py", line 197, in import_module mod = __import__(modname) File "E:\prj\src\lxml-0.8\src\lxml\tests\test_errors.py", line 9, in ? from lxml import etree ImportError: cannot import name etree
But if I run by hand, it works:
E:\prj\src\lxml-0.8>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
from lxml import etree ^Z
Is it possible that test.py is doing something with the pythonpath that might contribute to this oddness?
Is this this 'test.py' from the Zope trunk? I just fixed that recently: - --- Zope/branches/Zope-2_9-branch/test.py 2005-11-14 04:54:58 UTC (rev 40092) +++ Zope/branches/Zope-2_9-branch/test.py 2005-11-14 16:21:24 UTC (rev 40093) @@ -30,7 +30,7 @@ if shome: shome = os.path.abspath(shome) else: - - shome = os.path.join(zhome, 'lib/python') + shome = os.path.join(zhome, 'lib', 'python') elif shome: shome = os.path.abspath(shome) zhome = os.path.dirname(os.path.dirname(shome)) @@ -42,7 +42,7 @@ else: # No zope home, assume that it is the script directory zhome = os.path.abspath(os.path.dirname(sys.argv[0])) - - shome = os.path.join(zhome, 'lib/python') + shome = os.path.join(zhome, 'lib', 'python') sys.path.insert(0, shome) Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDgAaV+gerLs4ltQ4RAsDhAJ4kkqy6977Vca1+84ZtwzTkE4aoDACgyr3o /5plpC5JYLMtJ29MAtaPBtw= =clCl -----END PGP SIGNATURE-----
Brad Clements wrote:
I have lxml 0.8 compiled with the latest windows binaries from
http://xmlsoft.org/sources/win32/
python selftest.py passes, but python test.py fails oddly.
E:\prj\src\lxml-0.8>python test.py Traceback (most recent call last): File "test.py", line 591, in ? exitcode = main(sys.argv) File "test.py", line 554, in main test_cases = get_test_cases(test_files, cfg, tracer=tracer) File "test.py", line 254, in get_test_cases module = import_module(file, cfg, tracer=tracer) File "test.py", line 197, in import_module mod = __import__(modname) File "E:\prj\src\lxml-0.8\src\lxml\tests\test_errors.py", line 9, in ? from lxml import etree ImportError: cannot import name etree
Did you run python setup.py build_ext -i before this, just as the Makefile does? This builds the etree extension in-place, i.e. in the source directory. test.py uses "src/" in its PYTHONPATH, so the lxml package in src/ will be found, but if you did not build in-place, the etree extension will be missing. Stefan
On 20 Nov 2005 at 12:08, Stefan Behnel wrote:
Did you run python setup.py build_ext -i before this, just as the Makefile does?
No, I had done a 'setup.py install' now that I've done the build_ext -i and put the requisite dlls in my path, then python test.py does work. Thanks, -- But, if I then cd to site-packages/lxml/tests, then run python test_etree.py it fails with hundreds of errors, mostly because self.etree is None .. I guess these site-packages/lxml/tests are the same tests run by python test.py in the distribution directory, but I'm not launching them correctly.. -- Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com AOL-IM or SKYPE: BKClements
On 20 Nov 2005 at 0:16, Tres Seaver wrote:
Is this this 'test.py' from the Zope trunk? I just fixed that recently:
No, it says SchoolTool at the top of the file. However I was able to get the tests to work, I didn't follow the instructions.. sorry! Thanks for response.. -- Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com AOL-IM or SKYPE: BKClements
Tres Seaver wrote: [snip]
Is this this 'test.py' from the Zope trunk? I just fixed that recently:
No, I'm using test.py as ships with schooltool, which is a different implementation altogether. This isn't for deep reasons; I could get it to work without problems when I tried it. :) Regards, Martijn
Brad Clements wrote:
On 20 Nov 2005 at 0:16, Tres Seaver wrote:
Is this this 'test.py' from the Zope trunk? I just fixed that recently:
No, it says SchoolTool at the top of the file.
However I was able to get the tests to work, I didn't follow the instructions.. sorry!
Thanks for response..
I'm not sure whether you didn't follow the instructions; the instructions aren't very clear if they exist at all. :) Feel free to help out there. Anyway, the lxml tests currently are primarily meant for developers and I haven't given much thought to supporting people who package up lxml. The testrunner adds 'src' to the PYTHONPATH and if you've installed lxml it'll not find those installed binaries -- it'll go look for them in the 'src' directory, which won't contain them, if you've not built in-place. We've had this problem pop up a number of times in the past, so we should think about a way to support people who just want to see whether their compile/install works. That said, we wouldn't want any changes that will make life harder for the developers so we have to be careful there. Regards, Martijn
Martijn Faassen wrote:
Tres Seaver wrote: [snip]
Is this this 'test.py' from the Zope trunk? I just fixed that recently:
No, I'm using test.py as ships with schooltool, which is a different implementation altogether. This isn't for deep reasons; I could get it to work without problems when I tried it. :)
Have you considered switchting to the new zope.testing testrunner now shipping with Zope 2.9 and 3.2? I could stitch it in for you. Philipp
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
Tres Seaver wrote: [snip]
Is this this 'test.py' from the Zope trunk? I just fixed that recently:
No, I'm using test.py as ships with schooltool, which is a different implementation altogether. This isn't for deep reasons; I could get it to work without problems when I tried it. :)
Have you considered switchting to the new zope.testing testrunner now shipping with Zope 2.9 and 3.2? I could stitch it in for you.
Sure, I'm interested! But just to get it spelled out, what advantages would it offer? One I can think of (I think) is the ability to use the python debugger with doctests. That sounds useful. What else? Regards, Martijn
Martijn Faassen wrote:
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
Tres Seaver wrote: [snip]
Is this this 'test.py' from the Zope trunk? I just fixed that recently:
No, I'm using test.py as ships with schooltool, which is a different implementation altogether. This isn't for deep reasons; I could get it to work without problems when I tried it. :)
Have you considered switchting to the new zope.testing testrunner now shipping with Zope 2.9 and 3.2? I could stitch it in for you.
Sure, I'm interested! But just to get it spelled out, what advantages would it offer? One I can think of (I think) is the ability to use the python debugger with doctests. That sounds useful. What else?
Also, better doctest metrics (a doctest suite does not necessarily count as a single test anymore). Of course, there are features (like levels) that might not be too useful for lxml, but are very useful for integration-test environments like Zope. Philipp
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
Philipp von Weitershausen wrote: [snip]
Have you considered switchting to the new zope.testing testrunner now shipping with Zope 2.9 and 3.2? I could stitch it in for you.
Sure, I'm interested! But just to get it spelled out, what advantages would it offer? One I can think of (I think) is the ability to use the python debugger with doctests. That sounds useful. What else?
Also, better doctest metrics (a doctest suite does not necessarily count as a single test anymore).
That's cool too.
Of course, there are features (like levels) that might not be too useful for lxml, but are very useful for integration-test environments like Zope.
The one drawback is people who want to run the tests with an installed version of lxml instead (they may not have the needed zope 3 test libraries installed, though already this is a problem with the doctests). If you run it from the sandbox, it comes with the right zope stuff so it'll work. Still, I think I'm sold though. You'd be very welcome to integrate this stuff on a branch! Regards, Martijn
participants (5)
-
Brad Clements -
Martijn Faassen -
Philipp von Weitershausen -
Stefan Behnel -
Tres Seaver