[PATCH] autodetect top dir in downloaded libs
As of now, `setup.py --static --static-deps' fails with: <...> Retrieving "ftp://ftp.zlatkovic.com/pub/libxml/zlib-1.2.5.win32.zip" to "libs\zlib-1.2.5.win32.zip" Unpacking zlib-1.2.5.win32.zip into libs Traceback (most recent call last): <...> File "C:\Users\native_api\Documents\lxml\buildlibxml.py", line 47, in download_and_extract_zlatkovic_binaries d = unpack_zipfile(destfile, destdir) File "C:\Users\native_api\Documents\lxml\buildlibxml.py", line 62, in unpack_zipfile assert os.path.exists(edir), 'missing: %s' % edir AssertionError: missing: libs\zlib-1.2.5.win32 The reason is that the top level dir in ftp://ftp.zlatkovic.com/pub/libxml/zlib-1.2.5.win32.zip is `zlib-1.2.5', not `zlib-1.2.5.win32' as unpack_zipfile() expects. The patch provided autodetectes the top dir name in downloaded files which fixes the issue. Though the site's maintainer probably needs to fix the root cause too.
vano@mail.mipt.ru, 19.01.2014 01:14:
As of now, `setup.py --static --static-deps' fails with:
No need to pass "--static" as well.
Retrieving "ftp://ftp.zlatkovic.com/pub/libxml/zlib-1.2.5.win32.zip" to "libs\zlib-1.2.5.win32.zip" Unpacking zlib-1.2.5.win32.zip into libs Traceback (most recent call last): <...> File "C:\Users\native_api\Documents\lxml\buildlibxml.py", line 47, in download_and_extract_zlatkovic_binaries d = unpack_zipfile(destfile, destdir) File "C:\Users\native_api\Documents\lxml\buildlibxml.py", line 62, in unpack_zipfile assert os.path.exists(edir), 'missing: %s' % edir AssertionError: missing: libs\zlib-1.2.5.win32
The reason is that the top level dir in ftp://ftp.zlatkovic.com/pub/libxml/zlib-1.2.5.win32.zip is `zlib-1.2.5', not `zlib-1.2.5.win32' as unpack_zipfile() expects.
The patch provided autodetectes the top dir name in downloaded files which fixes the issue.
Thanks. I've rewritten your patch to also work in Py2.4: https://github.com/lxml/lxml/commit/930371bd85dff98a2dda9aab5d4e2f7938248410 Could you please test it? And then also run the test suite? Is that all you had to change to get it running for you?
Though the site's maintainer probably needs to fix the root cause too.
That would be good, yes. Stefan
As of now, `setup.py --static --static-deps' fails with:
No need to pass "--static" as well.
Retrieving "ftp://ftp.zlatkovic.com/pub/libxml/zlib-1.2.5.win32.zip" to "libs\zlib-1.2.5.win32.zip" Unpacking zlib-1.2.5.win32.zip into libs Traceback (most recent call last): <...> File "C:\Users\native_api\Documents\lxml\buildlibxml.py", line 47, in download_and_extract_zlatkovic_binaries d = unpack_zipfile(destfile, destdir) File "C:\Users\native_api\Documents\lxml\buildlibxml.py", line 62, in unpack_zipfile assert os.path.exists(edir), 'missing: %s' % edir AssertionError: missing: libs\zlib-1.2.5.win32
The reason is that the top level dir in ftp://ftp.zlatkovic.com/pub/libxml/zlib-1.2.5.win32.zip is `zlib-1.2.5', not `zlib-1.2.5.win32' as unpack_zipfile() expects.
The patch provided autodetectes the top dir name in downloaded files which fixes the issue.
Thanks. I've rewritten your patch to also work in Py2.4:
https://github.com/lxml/lxml/commit/930371bd85dff98a2dda9aab5d4e2f7938248410
Could you please test it? And then also run the test suite?
There are 3 failures: test_dtd_parse_file_not_found test_resolve_filename_dtd_relative test_xslt_resolver_url_building Output (with test list removed at moderator's insistence) is attached.
Is that all you had to change to get it running for you?
I also had to insert http://msinttypes.googlecode.com/svn/trunk/stdint.h to VC9.0's include dir so it compiled (as suggested @ http://stackoverflow.com/questions/126279/c99-stdint-h-header-and-ms-visual-...).
Though the site's maintainer probably needs to fix the root cause too.
That would be good, yes.
Stefan
vano@mail.mipt.ru, 20.01.2014 11:28:
There are 3 failures: test_dtd_parse_file_not_found test_resolve_filename_dtd_relative test_xslt_resolver_url_building
Output (with test list removed at moderator's insistence) is attached.
Thanks! I (think I) fixed some in latest master. Most of them seem to be due to file name handling, not sure where the problem might be here. Could also be in libxml2. I can't think of any recent changes in lxml that could be related here. Did any other MS-Windows users notice these before? Stefan
participants (2)
-
Stefan Behnel
-
vano@mail.mipt.ru