From: Jimmy R. <ji...@re...> - 2006-02-28 04:47:57
|
Jim Hargrave wrote: > Greg Lee wrote: > > In upgrading from 0.6.3 to 0.6.4 I encountered the following: > > > > Pyexe 0.6.4 with Python 2.4 does not find these modules: > > ['win32com.shell.shell', 'win32com.shell.shellcon', 'xml.xpath'] > > ... > > I'm also using pywin32 205 and PyXML 0.8.4. > > > > Finally, this more-or-less worked correctly in py2exe 0.6.3: the exe ran > > although some modules could not be found: > > ['DateTime', 'Ft.Lib', 'Ft.Lib.DumpBgTuple', 'Ft.__init__', > > 'XPathParserc', 'ext.IsDOMString', 'ext.SplitQName', 'xml.xslt', > > 'xml.xslt.ParsedPattern'] >=20 > Same here after an upgrade from 0.6.3 to 0.6.4. But I get: >=20 > The following modules appear to be missing > ['xml.sax.saxlib'] >=20 > I also have PyXML 0.8.4 and using the latest ActiveState Python 2.4.2 > Build 10 - this worked with py2exe 0.6.3. >=20 > Jim >=20 I don't use PyXML so I'm not too familiar with it. I installed it and I'm able to access basic xml.sax.saxlib APIs when using the following setup.py: from distutils.core import setup import py2exe setup( console=3D['test.py'], options=3D{ 'py2exe': { 'packages': ['_xmlplus'], } }, ) Was the specification of _xmlplus in the packages unnecessary before 0.6.4? Jimmy |
From: Greg L. <gl...@ph...> - 2006-03-06 21:54:05
|
Jim Hargrave wrote: >I don't use PyXML so I'm not too familiar with it. I installed it and >I'm able to access basic xml.sax.saxlib APIs when using the following >setup.py: >from distutils.core import setup >import py2exe >setup( console=3D['test.py'], > options=3D{ > 'py2exe': { > 'packages': ['_xmlplus'], > } > }, > ) >Was the specification of _xmlplus in the packages unnecessary before >0.6.4? >Jimmy Specifying _xmlplus in packages doesn't help: I get a different, larger = list of missing modules, mostly related to xml:=20 =20 ['DateTime', 'Ft.Lib', 'Ft.Lib.DumpBgTuple', 'Ft.__init__', 'XMLClient', = 'XMLFac tory', 'XMLinter', 'XPathParserc', 'com.indelv.dom', = 'com.indelv.dom.util', 'com .sun.xml.tree', 'ext.IsDOMString', 'ext.SplitQName', 'fr.loria.xml', = 'java.io', 'java.net', 'javax.xml.parsers', 'org.apache.xerces.dom', = 'org.apache.xerces.par sers', 'org.brownell.xml', 'org.brownell.xml.dom', 'org.openxml.dom', = 'org.openx ml.parser', 'org.w3c.dom', 'org.xml.sax', 'org.xml.sax.helpers', = 'saxlib', 'xml. FtCore', 'xml.dom.Attr', 'xml.dom.BAD_BOUNDARYPOINTS_ERR', = 'xml.dom.BadBoundaryP ointsErr', 'xml.dom.DOMImplementation', 'xml.dom.Document', = 'xml.dom.DocumentTyp e', 'xml.dom.Element', 'xml.dom.Entity', = 'xml.dom.INVALID_NODE_TYPE_ERR', 'xml.d om.InvalidNodeTypeErr', 'xml.dom.NodeIterator', 'xml.dom.Text', = 'xml.dom.UNSPECI FIED_EVENT_TYPE_ERR', 'xml.dom.UnspecifiedEventTypeErr', = 'xml.dom.XML_PARSE_ERR' , 'xml.dom.ext', 'xml.dom.ext.Visitor', 'xml.dom.ext.reader', = 'xml.dom.ext.reade r.HtmlLib', 'xml.dom.html', 'xml.dom.html.HTMLCollection', = 'xml.dom.html.HTMLEle ment', 'xml.dom.implementation', 'xml.ns', 'xml.parsers.pyexpat', = 'xml.parsers.s gmllib', 'xml.parsers.sgmlop', 'xml.parsers.xmlproc', = 'xml.parsers.xmlproc.dtdpa rser', 'xml.parsers.xmlproc.xmlapp', 'xml.sax.drivers', = 'xml.sax.drivers.drv_xml proc', 'xml.sax.sax2exts', 'xml.sax.saxexts', 'xml.sax.saxlib', = 'xml.unicode.iso 8859', 'xml.utils', 'xml.utils.characters', 'xml.xpath', = 'xml.xpath.ParsedAbbrev iatedAbsoluteLocationPath', = 'xml.xpath.ParsedAbbreviatedRelativeLocationPath', ' xml.xpath.ParsedAbsoluteLocationPath', 'xml.xpath.ParsedAxisSpecifier', = 'xml.xpa th.ParsedPredicateList', 'xml.xpath.ParsedRelativeLocationPath', = 'xml.xpath.Pars edStep', 'xml.xslt', 'xml.xslt.ParsedPattern', 'xml_dc'] Other respondents have suggested excluding xml, but my application uses = PyXML. (BTW: I confirmed that using py2exe.mf as modulefinder solved the shell = problem; I've been out of town and was unable to do this before today. = Thanks.) |
From: Greg L. <gl...@ph...> - 2006-03-06 22:50:38
|
Jimmy Retzlaff wrote: >I don't use PyXML so I'm not too familiar with it. I installed it and >I'm able to access basic xml.sax.saxlib APIs when using the following >setup.py: >from distutils.core import setup >import py2exe >setup( > console=3D['test.py'], > options=3D{ > 'py2exe': { > 'packages': ['_xmlplus'], > } > }, > ) >Was the specification of _xmlplus in the packages unnecessary before >0.6.4? >Jimmy Here's a simple failure. Consider importtest.py consisting solely of: import xml.xpath with this setup.py: # setup.py # python setup.py py2exe (or python setup24.py py2exe) # you may need to 'rm -rf dist build' first. from distutils.core import setup import glob import py2exe import sys # The Target class is demonstrated in py2exe/samples/advanced/setup.py class Target: def __init__(self, name, **kw): self.__dict__.update(kw) self.__dict__["script"] =3D "importtest.py" # for the versioninfo resources self.company_name =3D "Pharsight Corporation" self.copyright =3D "2002, 2003, 2004, 2005" self.name =3D name # The console version shows stdout messages in a DOS box. setup(name=3D"importtest", windows=3D[Target("Import Test", description=3D"Import Test") ], console=3D[Target("Import Test (console)", dest_base=3D"console", description=3D"Console version of Import Test")], version =3D "1.4.0.000", options=3D{"py2exe":{"packages":[]}} \ ) Python can resolve "import xml.xpath" interactively, but py2exe fails to = resolve. |
From: Jimmy R. <ji...@re...> - 2006-03-07 08:31:46
|
In case anyone hasn't noticed, I broke a bunch of things in py2exe 0.6.4. :( They all seem to surround the way I incorporated Thomas' performance enhancements for modulefinder - just to be clear, the issues have nothing to do with Thomas' new code, they all come from the way I incorporated it. The primary issue has to do with the duplication of some data structures between Python's modulefinder and py2exe.mf. This has surfaced a number of times as problems including various xml modules. I also completely left out the code that implements the xref functionality of earlier versions of py2exe. I believe I've rectified these problems in a new version of py2exe.mf. There have been a number of cases where I've recommended replacing "import modulefinder" with "import py2exe.mf as modulefinder" since 0.6.4 was released... this fix should allow you to go back to the former (although the latter will continue to work as well). I would appreciate it if some of you who have been experiencing problems since upgrading to 0.6.4 could try out the new module and let me know how it works for you. If all goes well then I will release 0.6.5 soon which will simply consist of these fixes applied to 0.6.4. To try it out, download mf.py and drop it in your py2exe directory (typically something like C:\Python24\Lib\site-packages\py2exe). The new version is in CVS, but I have no idea when the anonymous mirror will be updated, so I've made it available at http://www.py2exe.org/mf.py. Jimmy |
From: Russell E. O. <ro...@ce...> - 2006-03-08 01:17:31
|
In article <A7B5C22F20EE3C4E95744E2F03F1887F456198@MAYOR.retzlaff.com>, "Jimmy Retzlaff" <ji...@re...> wrote: > In case anyone hasn't noticed, I broke a bunch of things in py2exe > 0.6.4....I believe I've rectified these problems in a new version of py2exe.mf. > There have been a number of cases where I've recommended replacing > "import modulefinder" with "import py2exe.mf as modulefinder" since > 0.6.4 was released... this fix should allow you to go back to the former > (although the latter will continue to work as well).... I tried your modified mf.py (thanks much for the direct link) and it worked for me. I imported modulefinder instead of using py2exe.mf (the old way that worked before 0.6.4) and win32com.shell was found just fine. Thanks for the fix! At risk of sounding ungrateful, I'm curious if there is a long-term likelihood that py2exe will be able to find win32com and other such packages by itself (i.e. the packages that currently need playing with modulefinder or py2exe.mf to be found)? -- Russell |
From: Greg L. <gl...@ph...> - 2006-03-07 21:49:31
|
Jimmy Retzlaff wrote: >I would appreciate it if some of you who have been experiencing = problems >since upgrading to 0.6.4 could try out the new module and let me know >how it works for you. If all goes well then I will release 0.6.5 soon >which will simply consist of these fixes applied to 0.6.4. This seems to get us back to 0.6.3 behavior, i.e. I have the same list = of missing modules as with 0.6.3 for "import xml.xpath": The following modules appear to be missing ['DateTime', 'Ft.Lib', 'Ft.Lib.DumpBgTuple', 'Ft.__init__', = 'XPathParserc', 'ext.IsDOMString', 'ext.SplitQName', 'xml.xslt', = 'xml.xslt.ParsedPattern'] 1. This is better than 0.6.4 2. I'd be grateful if someone could tell me how to fix the remaining = missing modules. I think they "don't matter", but it worries me... The = Python module finder does not have this problem. Thanks |
From: Jimmy R. <ji...@re...> - 2006-03-07 22:50:41
|
Greg Lee wrote: > Jimmy Retzlaff wrote: > >I would appreciate it if some of you who have been experiencing problems > >since upgrading to 0.6.4 could try out the new module and let me know > >how it works for you. If all goes well then I will release 0.6.5 soon > >which will simply consist of these fixes applied to 0.6.4. >=20 > This seems to get us back to 0.6.3 behavior, i.e. I have the same list of > missing modules as with 0.6.3 for "import xml.xpath": That's good news, thanks. > The following modules appear to be missing > ['DateTime', 'Ft.Lib', 'Ft.Lib.DumpBgTuple', 'Ft.__init__', > 'XPathParserc', 'ext.IsDOMString', 'ext.SplitQName', 'xml.xslt', > 'xml.xslt.ParsedPattern'] >=20 > 1. This is better than 0.6.4 > 2. I'd be grateful if someone could tell me how to fix the remaining > missing modules. I think they "don't matter", but it worries me... The > Python module finder does not have this problem. I'm not sure what you mean by the "Python module finder." Python's modulefinder is what is used in 0.6.3, and a modified version is used in 0.6.4 (with or without the fix). Perhaps you mean Python's import mechanism? The difference there is that the import mechanism only looks for modules when it comes across the import whereas modulefinder (and therefore py2exe) looks for all import statements regardless of whether they are reachable in your code. Take DateTime in your example. If you look through PyXML, you'll find that it is only imported when you call the IsoTime function - if you don't call it then Python will never look for it. py2exe will notice the import and try to grab it, however, because it can't tell if that code is reachable in your program or not. This is often not a fatal error so py2exe warns you about it and continues. This delayed import technique is often used to reduce the interdependence of different modules. So, for example, you don't have to install DateTime to use PyXML unless you use the specific part of PyXML that requires it. It is also used for platform dependent code where you'll see something like: if 'posix' in _names: import posixpath as path elif 'nt' in _names: import ntpath as path elif 'mac' in _names: import macpath as path else: raise ImportError, 'no os specific module found' Jimmy |
From: Greg L. <gl...@ph...> - 2006-03-07 23:02:12
|
Jimmy Retzlaff wrote: >I'm not sure what you mean by the "Python module finder." Python's >modulefinder is what is used in 0.6.3, and a modified version is used = in >0.6.4 (with or without the fix). Perhaps you mean Python's import >mechanism? The difference there is that the import mechanism only looks >for modules when it comes across the import whereas modulefinder (and >therefore py2exe) looks for all import statements regardless of whether >they are reachable in your code. Thank you for the clarification. I drew the wrong conclusion from = comments in mf.py about "the real Python modulefinder". >Take DateTime in your example. If you look through PyXML, you'll find >that it is only imported when you call the IsoTime function - if you >don't call it then Python will never look for it. py2exe will notice = the >import and try to grab it, however, because it can't tell if that code >is reachable in your program or not. This is often not a fatal error so >py2exe warns you about it and continues. This seems to mean that I need to use static analysis or thorough = testing to convince myself that each of the supposedly missing modules = is not reachable in my code. Thanks (Also thanks for taking over support of py2exe.) |
From: Jim H. <jha...@co...> - 2006-02-28 06:01:16
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <pre wrap="">>>Was the specification of _xmlplus in the packages unnecessary before >>0.6.4? That's correct. In 0.6.3 no extra configuration is needed. At least for my application. Jim </pre> <br> <br> Jimmy Retzlaff wrote: <blockquote cite="midA7B5C22F20EE3C4E95744E2F03F1887F4560F3@MAYOR.retzlaff.com" type="cite"> <pre wrap="">Jim Hargrave wrote: </pre> <blockquote type="cite"> <pre wrap="">Greg Lee wrote: </pre> <blockquote type="cite"> <pre wrap="">In upgrading from 0.6.3 to 0.6.4 I encountered the following: Pyexe 0.6.4 with Python 2.4 does not find these modules: ['win32com.shell.shell', 'win32com.shell.shellcon', 'xml.xpath'] </pre> </blockquote> </blockquote> <pre wrap=""><!---->... </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">I'm also using pywin32 205 and PyXML 0.8.4. Finally, this more-or-less worked correctly in py2exe 0.6.3: the exe </pre> </blockquote> </blockquote> <pre wrap=""><!---->ran </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">although some modules could not be found: ['DateTime', 'Ft.Lib', 'Ft.Lib.DumpBgTuple', 'Ft.__init__', 'XPathParserc', 'ext.IsDOMString', 'ext.SplitQName', 'xml.xslt', 'xml.xslt.ParsedPattern'] </pre> </blockquote> <pre wrap="">Same here after an upgrade from 0.6.3 to 0.6.4. But I get: The following modules appear to be missing ['xml.sax.saxlib'] I also have PyXML 0.8.4 and using the latest ActiveState Python 2.4.2 Build 10 - this worked with py2exe 0.6.3. Jim </pre> </blockquote> <pre wrap=""><!----> I don't use PyXML so I'm not too familiar with it. I installed it and I'm able to access basic xml.sax.saxlib APIs when using the following setup.py: from distutils.core import setup import py2exe setup( console=['test.py'], options={ 'py2exe': { 'packages': ['_xmlplus'], } }, ) Was the specification of _xmlplus in the packages unnecessary before 0.6.4? Jimmy </pre> </blockquote> <br> </body> </html> |
From: Sreeram K. <sr...@ta...> - 2006-02-28 08:21:36
|
I've attached a simple program which uses elementtree. This program fails with an ImportError with py2exe 0.6.4, if PyXML is also installed. Version 0.6.3 works perfectly. One workaround to make this program work is to add an exclude for '_xmlplus' (alternatively uninstalling PyXML also works!) Regards Sreeram |
From: Thomas H. <th...@py...> - 2006-02-28 21:03:27
|
Jimmy Retzlaff wrote: > Jim Hargrave wrote: >> Greg Lee wrote: >>> In upgrading from 0.6.3 to 0.6.4 I encountered the following: >>> >>> Pyexe 0.6.4 with Python 2.4 does not find these modules: >>> ['win32com.shell.shell', 'win32com.shell.shellcon', 'xml.xpath'] >>> > ... >>> I'm also using pywin32 205 and PyXML 0.8.4. >>> >>> Finally, this more-or-less worked correctly in py2exe 0.6.3: the exe > ran >>> although some modules could not be found: >>> ['DateTime', 'Ft.Lib', 'Ft.Lib.DumpBgTuple', 'Ft.__init__', >>> 'XPathParserc', 'ext.IsDOMString', 'ext.SplitQName', 'xml.xslt', >>> 'xml.xslt.ParsedPattern'] >> Same here after an upgrade from 0.6.3 to 0.6.4. But I get: >> >> The following modules appear to be missing >> ['xml.sax.saxlib'] >> >> I also have PyXML 0.8.4 and using the latest ActiveState Python 2.4.2 >> Build 10 - this worked with py2exe 0.6.3. >> >> Jim >> > > I don't use PyXML so I'm not too familiar with it. I installed it and > I'm able to access basic xml.sax.saxlib APIs when using the following > setup.py: > > from distutils.core import setup > import py2exe > > setup( > console=['test.py'], > options={ > 'py2exe': { > 'packages': ['_xmlplus'], > } > }, > ) > > > Was the specification of _xmlplus in the packages unnecessary before > 0.6.4? modulefinder has a mechanism to handle this: ReplacePackage. It seems this method (in py2exe\build_exe.py): def create_modulefinder(self): from modulefinder import ReplacePackage from py2exe.mf import ModuleFinder ReplacePackage("_xmlplus", "xml") return ModuleFinder(excludes=self.excludes) should be replaced with: def create_modulefinder(self): from py2exe.mf import ModuleFinder, ReplacePackage ReplacePackage("_xmlplus", "xml") return ModuleFinder(excludes=self.excludes) Thomas |