From: Don D. <ddw...@ad...> - 2013-04-11 02:49:24
|
I have aWindows service that I distributein "compiled" form, using py2exe. This has been working well, but I recently ran into a problem. I've converted the database access to use SQLAlchemy (SA). This code works well from source, but the py2exe-built executable fails on startup. The problem is related to thefact that SA uses "drivers" for various databasetypes toencapsulate the differences among SQL dialects. To create a connection, I pass a string starting with "mssql+pyodbc//...", which tells SA to use the MS SQL dialect through an ODBC connection. SA has a folder containing code forthe various dialects; it parses the prefix, and calls __import__ to get the appropriate modules. The frozen code gets an ImportError when trying to do this. I've tried putting 'sqlalchemy.dialects' in the includes, and in the packages. I've also tried 'sqlalchemy.dialects.mssql' and 'sqlalchemy.dialects.mssql.pyodbc'; no luck with either. >From the py2exe printed output, I've seen that it's accessing the dialects folder (at least byte compiling it). Beyond that, I'm not sure whether or how it gets packaged in the executable. So, I'm asking if there's some way to find out why it's failing to find the appropriate modules, or even better, how to tweak the options in setup.py to fix the problem. Thanks, -- Don Dwiggins Advanced Publishing Technology |
From: Don D. <ddw...@ad...> - 2013-04-29 19:28:49
|
I have aWindows service that I distributein "compiled" form, using py2exe. This has been working well, but I recently ran into a problem. Itworks when starting from source, but the py2exe-built executable fails on startupwith the message "Error starting service: The service did not respond to the start or control request in a timely fashion." This message comes up immediately, so it's pretty clearly not time-related. I've been digging into the win32serviceutil code, and I've found a clue: if I start the service in debug mode, it works without a problem. This seems to be related to the fact that the service class I pass to HandleCommandLine is only instantiated by the DebugService method. StartService never instantiates it, only using it to get the _svc_* attributes. So, the ServiceFramework.__init__ method never gets called, and that's where it registers itself to the service manager. For what it's worth, I've been using this service for quite a while, developing it on an old Win XP machine. The trouble started when I moved over to a new Win 7 Professional system. Have there been some changes in py2exe or pywin32 that might relate to this? Thanks for any good words, -- Don Dwiggins Advanced Publishing Technology |
From: Manuel S. <mj...@sa...> - 2013-04-29 21:12:59
|
Hi Don, You can use event viewer to debug. If you can't find any message in the event viewer than it is must be in your setup file. Can you show us your setup file? I've found some differences between starting from source and running the .exe while accesing files and parsing arguments. Any of these in your code? /Cumprimentos/ /Manuel Silva/ Quoting Don Dwiggins <ddw...@ad...>: > > I have a Windows service that I distribute in "compiled" form, using > py2exe. This has been working well, but I recently ran into a > problem. It works when starting from source, but the py2exe-built > executable fails on startup with the message "Error starting > service: The service did not respond to the start or control request > in a timely fashion." This message comes up immediately, so it's > pretty clearly not time-related. > > I've been digging into the win32serviceutil code, and I've found > a clue: if I start the service in debug mode, it works without a > problem. This seems to be related to the fact that the service > class I pass to HandleCommandLine is only instantiated by the > DebugService method. StartService never instantiates it, only using > it to get the _svc_* attributes. So, the ServiceFramework.__init__ > method never gets called, and that's where it registers itself to > the service manager. > > For what it's worth, I've been using this service for quite a > while, developing it on an old Win XP machine. The trouble started > when I moved over to a new Win 7 Professional system. Have there > been some changes in py2exe or pywin32 that might relate to this? > > Thanks for any good words, > -- > Don Dwiggins Advanced Publishing Technology > |
From: Don D. <ddw...@ad...> - 2013-04-30 16:15:45
|
Thanks for the reply... On 4/29/13 2:12 PM, Manuel Silva wrote: > > Hi Don, > You can use event viewer to debug. If you can't find any message in > the event viewer than it is must be in your setup file. > There's no events showing. I doubt that it's the setup file, since the frozen executable works (starts and serves requests successfully) in debug mode. > Can you show us your setup file? > See below. > I've found some differences between starting from source and running > the .exe while accesing files and parsing arguments. Any of these in > your code? > I've run into that too (running in a different folder in source vs. the executable), and coded around it. It's not an issue here, though. I'm really curious why win32serviceutil doesn't instantiate the service class during "start" processing, especially since it's in ServiceFramework.__init__ that servicemanager.RegisterServiceCtrlHandler gets called. Perhaps I should mention that I'm using a recent Activestate 2.7 distribution, which includes the win32 packages. Here's the setup.py: > from distutils.core import setup > import py2exe > import sys, os, shutil > > class Target: > def __init__(self, **kw): > self.__dict__.update(kw) > # for the versioninfo resources > self.version = "0.5.0" > self.company_name = "Advanced Publishing Technology" > self.copyright = "" > self.name = "Remote Client Access (RCA) Server" > > RCAservice = Target( > # Used for the versioninfo resource > description = "APT Circulation -- Remote Client Access Service", > # What to build. For a service, the module name (not the > # filename) must be specified! > modules = ["RCAServer"], > cmdline_style='pywin32', > ) > > setup( > service = [RCAservice], > options = {"py2exe": {"compressed": 1, > "optimize": 2, > "bundle_files": 1, > 'includes':['pyodbc', > 'twisted.web.resource', 'decimal', > # Needed for Python 2.5 lib -- > also the ignores below > 'email.utils', > 'email.base64mime', > 'email.generator', > 'email.iterators', > ], > 'packages': [# The following to allow SA to > find the MSSQL dialect > 'sqlalchemy.dialects', > ##'sqlalchemy.dialects.mssql', > ##'sqlalchemy.dialects.mssql.pyodbc', > ], > 'ignores':['FCNTL', 'OpenSSL', 'resource', > 'email.Utils', 'email.base64MIME', > 'email.Iterators', > 'email.Generator'], > 'dll_excludes': [ "mswsock.dll", > "powrprof.dll" ] > }}, > zipfile = None , > ) -- Don Dwiggins Advanced Publishing Technology |
From: Mark H. <ski...@gm...> - 2013-04-30 23:08:58
|
On 1/05/2013 2:15 AM, Don Dwiggins wrote: > Thanks for the reply... > > On 4/29/13 2:12 PM, Manuel Silva wrote: >> >> Hi Don, >> You can use event viewer to debug. If you can't find any message in >> the event viewer than it is must be in your setup file. >> > There's no events showing. I doubt that it's the setup file, since the > frozen executable works (starts and serves requests successfully) in > debug mode. You might want to instrument your service so you can narrow down where the failure is - eg, add your own lines to print to the event log or to win32traceutil. > >> Can you show us your setup file? >> > > See below. > >> I've found some differences between starting from source and running >> the .exe while accesing files and parsing arguments. Any of these in >> your code? >> > > I've run into that too (running in a different folder in source vs. the > executable), and coded around it. It's not an issue here, though. Also you will be running as a different user. This generally means no network access. > I'm really curious why win32serviceutil doesn't instantiate the service > class during "start" processing, especially since it's in > ServiceFramework.__init__ that servicemanager.RegisterServiceCtrlHandler > gets called. I assume you have tested your service without py2exe, so win32serviceutil must be doing the right thing. FWIW, win32serviceutil's implementation of "start" just asks Windows to start the service. That process ends up looking in the registry for the executable specified for the named service and starting it. At this point, pythonservice.exe is what is used (or a py2exe built exe in this case), and it then also looks up the registry to find the classname, and *it* instantiates the class. Thus, win32serviceutil's process is *not* the service process - except in debug mode. HTH, Mark > > Perhaps I should mention that I'm using a recent Activestate 2.7 > distribution, which includes the win32 packages. > > Here's the setup.py: >> from distutils.core import setup >> import py2exe >> import sys, os, shutil >> >> class Target: >> def __init__(self, **kw): >> self.__dict__.update(kw) >> # for the versioninfo resources >> self.version = "0.5.0" >> self.company_name = "Advanced Publishing Technology" >> self.copyright = "" >> self.name = "Remote Client Access (RCA) Server" >> >> RCAservice = Target( >> # Used for the versioninfo resource >> description = "APT Circulation -- Remote Client Access Service", >> # What to build. For a service, the module name (not the >> # filename) must be specified! >> modules = ["RCAServer"], >> cmdline_style='pywin32', >> ) >> >> setup( >> service = [RCAservice], >> options = {"py2exe": {"compressed": 1, >> "optimize": 2, >> "bundle_files": 1, >> 'includes':['pyodbc', >> 'twisted.web.resource', 'decimal', >> # Needed for Python 2.5 lib -- >> also the ignores below >> 'email.utils', >> 'email.base64mime', >> 'email.generator', >> 'email.iterators', >> ], >> 'packages': [# The following to allow SA to >> find the MSSQL dialect >> 'sqlalchemy.dialects', >> ##'sqlalchemy.dialects.mssql', >> ##'sqlalchemy.dialects.mssql.pyodbc', >> ], >> 'ignores':['FCNTL', 'OpenSSL', 'resource', >> 'email.Utils', 'email.base64MIME', >> 'email.Iterators', >> 'email.Generator'], >> 'dll_excludes': [ "mswsock.dll", >> "powrprof.dll" ] >> }}, >> zipfile = None , >> ) > |
From: Don D. <ddw...@ad...> - 2013-05-03 01:06:30
|
Mark, Thanks for staying with me on this. > > Also note that service support is implements mainly via > py2exe/boot_service.py, so if instrumenting your service code seems to > show your module never being loaded, try instrumenting that file and > rebuilding to see what it tells you. I've instrumented boot_service as well, and included PID values in the log files, so I could see what was going on with the two processes involved. Doing this, I found some interesting information, and what I think is causing it to fail: * As you no doubt already know, the second process doesn't have the same working directory; in this case, it's in /Windows/System32. * The first process (the one I start from the command line has argv = ['C:\\Dwig\\tmp\\TestRCA\\RCAServer.exe', 'start'], which is OK. The second process, though, has argv = ['C:\\Dwig\\tmp\\TestRCA\\RCAServer.exe', 'C:\\Dwig\\tmp\\TestRCA'], so the second argument isn't "start", but the path to the starting working directory. * I'm using 'pywin32' as the command line style; given the argv, this will call win32serviceutil.HandleCommandLine(k). * So, in the second process, HandleCommandLine's initial setup code winds up with "arg" = 'C:\\Dwig\\tmp\\TestRCA', which isn't recognized as a command, so nothing gets done. I haven't figured out yet just how the second process gets started, much less why it gets a different argument. (Well, given that it's started in a system folder, I can see the logic for telling it where to find the original working directory.) As I mentioned before, this headache started when I tried to build the service on my new 64 bit Win 7 Pro machine (with 32 bit python and py2exe); I'd been developing and deploying the service successfully, with the same code, on my 32 bit Win XP machine for quite a while. I keep thinking that something must have changed in the environment to cause this... Fingers crossed, Don > > > HTH, > > Mark >> I don''t know if I mentioned, but this is happening on a Windows 7 >> Professional OS, 64 bit (but with 32 bit Python 2.7 and py2exe). >> >> >> Hope this gives enough information to give you a clue... >> >> >> Don >> >>> HTH, >>> >>> Mark >>> >>>> Perhaps I should mention that I'm using a recent Activestate 2.7 >>>> distribution, which includes the win32 packages. >>>> >>>> Here's the setup.py: >>>>> from distutils.core import setup >>>>> import py2exe >>>>> import sys, os, shutil >>>>> >>>>> class Target: >>>>> def __init__(self, **kw): >>>>> self.__dict__.update(kw) >>>>> # for the versioninfo resources >>>>> self.version = "0.5.0" >>>>> self.company_name = "Advanced Publishing Technology" >>>>> self.copyright = "" >>>>> self.name = "Remote Client Access (RCA) Server" >>>>> >>>>> RCAservice = Target( >>>>> # Used for the versioninfo resource >>>>> description = "APT Circulation -- Remote Client Access Service", >>>>> # What to build. For a service, the module name (not the >>>>> # filename) must be specified! >>>>> modules = ["RCAServer"], >>>>> cmdline_style='pywin32', >>>>> ) >>>>> >>>>> setup( >>>>> service = [RCAservice], >>>>> options = {"py2exe": {"compressed": 1, >>>>> "optimize": 2, >>>>> "bundle_files": 1, >>>>> 'includes':['pyodbc', >>>>> 'twisted.web.resource', 'decimal', >>>>> # Needed for Python 2.5 lib -- >>>>> also the ignores below >>>>> 'email.utils', >>>>> 'email.base64mime', >>>>> 'email.generator', >>>>> 'email.iterators', >>>>> ], >>>>> 'packages': [# The following to allow SA to >>>>> find the MSSQL dialect >>>>> 'sqlalchemy.dialects', >>>>> ##'sqlalchemy.dialects.mssql', >>>>> ##'sqlalchemy.dialects.mssql.pyodbc', >>>>> ], >>>>> 'ignores':['FCNTL', 'OpenSSL', 'resource', >>>>> 'email.Utils', 'email.base64MIME', >>>>> 'email.Iterators', >>>>> 'email.Generator'], >>>>> 'dll_excludes': [ "mswsock.dll", >>>>> "powrprof.dll" ] >>>>> }}, >>>>> zipfile = None , >>>>> ) >>> ------------------------------------------------------------------------------ >>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >>> Get 100% visibility into your production application - at no cost. >>> Code-level diagnostics for performance bottlenecks with <2% overhead >>> Download for free and get started troubleshooting in minutes. >>> http://p.sf.net/sfu/appdyn_d2d_ap1 >> >> >> ------------------------------------------------------------------------------ >> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >> Get 100% visibility into your production application - at no cost. >> Code-level diagnostics for performance bottlenecks with <2% overhead >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap1 >> _______________________________________________ >> Py2exe-users mailing list >> Py2...@li... >> https://lists.sourceforge.net/lists/listinfo/py2exe-users >> > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 |
From: Mark H. <ski...@gm...> - 2013-05-03 04:25:37
|
On 3/05/2013 11:05 AM, Don Dwiggins wrote: > Mark, > > Thanks for staying with me on this. >> >> Also note that service support is implements mainly via >> py2exe/boot_service.py, so if instrumenting your service code seems to >> show your module never being loaded, try instrumenting that file and >> rebuilding to see what it tells you. > > I've instrumented boot_service as well, and included PID values in the > log files, so I could see what was going on with the two processes > involved. Doing this, I found some interesting information, and what I > think is causing it to fail: > > * As you no doubt already know, the second process doesn't have the > same working directory; in this case, it's in /Windows/System32. This second process seems to be the service itself (which makes sense) > * The first process (the one I start from the command line has argv = > ['C:\\Dwig\\tmp\\TestRCA\\RCAServer.exe', 'start'], which is OK. > The second process, though, has argv = > ['C:\\Dwig\\tmp\\TestRCA\\RCAServer.exe', 'C:\\Dwig\\tmp\\TestRCA'], > so the second argument isn't "start", but the path to the starting > working directory. > > * I'm using 'pywin32' as the command line style; given the argv, this > will call win32serviceutil.HandleCommandLine(k). > > * So, in the second process, HandleCommandLine's initial setup code > winds up with "arg" = 'C:\\Dwig\\tmp\\TestRCA', which isn't > recognized as a command, so nothing gets done. Right! What *should* be happening is that the service gets started with no args, so RegisterServiceCtrlHandlerEx() gets called - this is what isn't happening here. > > I haven't figured out yet just how the second process gets started, much > less why it gets a different argument. (Well, given that it's started > in a system folder, I can see the logic for telling it where to find the > original working directory.) The second process will be created by the Service Control Manager, but I too don't know where that second argument comes from - and almost certainly it is the root cause of the problem. I'd be inclined to call this a bug in py2exe - it should probably just attempt to start the service whenever the command-line isn't recognized, rather than only when no args are specified. I'd love to know where that arg array comes from though - it may well be something specific to x64 Windows or just Windows 7. It would be interesting to know what sys.argv is from the service process when running the service via src - if it is exactly the same, then I'd infer it is just windows trying to be helpful or something :) Mark > > As I mentioned before, this headache started when I tried to build the > service on my new 64 bit Win 7 Pro machine (with 32 bit python and > py2exe); I'd been developing and deploying the service successfully, > with the same code, on my 32 bit Win XP machine for quite a while. I > keep thinking that something must have changed in the environment to > cause this... > > > Fingers crossed, > Don > >> >> >> HTH, >> >> Mark >>> I don''t know if I mentioned, but this is happening on a Windows 7 >>> Professional OS, 64 bit (but with 32 bit Python 2.7 and py2exe). >>> >>> >>> Hope this gives enough information to give you a clue... >>> >>> >>> Don >>> >>>> HTH, >>>> >>>> Mark >>>> >>>>> Perhaps I should mention that I'm using a recent Activestate 2.7 >>>>> distribution, which includes the win32 packages. >>>>> >>>>> Here's the setup.py: >>>>>> from distutils.core import setup >>>>>> import py2exe >>>>>> import sys, os, shutil >>>>>> >>>>>> class Target: >>>>>> def __init__(self, **kw): >>>>>> self.__dict__.update(kw) >>>>>> # for the versioninfo resources >>>>>> self.version = "0.5.0" >>>>>> self.company_name = "Advanced Publishing Technology" >>>>>> self.copyright = "" >>>>>> self.name = "Remote Client Access (RCA) Server" >>>>>> >>>>>> RCAservice = Target( >>>>>> # Used for the versioninfo resource >>>>>> description = "APT Circulation -- Remote Client Access Service", >>>>>> # What to build. For a service, the module name (not the >>>>>> # filename) must be specified! >>>>>> modules = ["RCAServer"], >>>>>> cmdline_style='pywin32', >>>>>> ) >>>>>> >>>>>> setup( >>>>>> service = [RCAservice], >>>>>> options = {"py2exe": {"compressed": 1, >>>>>> "optimize": 2, >>>>>> "bundle_files": 1, >>>>>> 'includes':['pyodbc', >>>>>> 'twisted.web.resource', 'decimal', >>>>>> # Needed for Python 2.5 lib -- >>>>>> also the ignores below >>>>>> 'email.utils', >>>>>> 'email.base64mime', >>>>>> 'email.generator', >>>>>> 'email.iterators', >>>>>> ], >>>>>> 'packages': [# The following to allow SA to >>>>>> find the MSSQL dialect >>>>>> 'sqlalchemy.dialects', >>>>>> ##'sqlalchemy.dialects.mssql', >>>>>> ##'sqlalchemy.dialects.mssql.pyodbc', >>>>>> ], >>>>>> 'ignores':['FCNTL', 'OpenSSL', 'resource', >>>>>> 'email.Utils', 'email.base64MIME', >>>>>> 'email.Iterators', >>>>>> 'email.Generator'], >>>>>> 'dll_excludes': [ "mswsock.dll", >>>>>> "powrprof.dll" ] >>>>>> }}, >>>>>> zipfile = None , >>>>>> ) >>>> ------------------------------------------------------------------------------ >>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >>>> Get 100% visibility into your production application - at no cost. >>>> Code-level diagnostics for performance bottlenecks with <2% overhead >>>> Download for free and get started troubleshooting in minutes. >>>> http://p.sf.net/sfu/appdyn_d2d_ap1 >>> >>> >>> ------------------------------------------------------------------------------ >>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >>> Get 100% visibility into your production application - at no cost. >>> Code-level diagnostics for performance bottlenecks with <2% overhead >>> Download for free and get started troubleshooting in minutes. >>> http://p.sf.net/sfu/appdyn_d2d_ap1 >>> _______________________________________________ >>> Py2exe-users mailing list >>> Py2...@li... >>> https://lists.sourceforge.net/lists/listinfo/py2exe-users >>> >> >> ------------------------------------------------------------------------------ >> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >> Get 100% visibility into your production application - at no cost. >> Code-level diagnostics for performance bottlenecks with <2% overhead >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap1 > > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > > > > _______________________________________________ > Py2exe-users mailing list > Py2...@li... > https://lists.sourceforge.net/lists/listinfo/py2exe-users > |
From: Don D. <ddw...@ad...> - 2013-05-03 16:32:51
|
On 5/2/13 9:25 PM, Mark Hammond wrote: >> I haven't figured out yet just how the second process gets started, much >> less why it gets a different argument. (Well, given that it's started >> in a system folder, I can see the logic for telling it where to find the >> original working directory.) > The second process will be created by the Service Control Manager, but I > too don't know where that second argument comes from - and almost > certainly it is the root cause of the problem. > > I'd be inclined to call this a bug in py2exe - it should probably just > attempt to start the service whenever the command-line isn't recognized, > rather than only when no args are specified. I'd love to know where > that arg array comes from though - it may well be something specific to > x64 Windows or just Windows 7. It would be interesting to know what > sys.argv is from the service process when running the service via src - > if it is exactly the same, then I'd infer it is just windows trying to > be helpful or something :) When I have a chance, I'll put a "sleep(60)" early in the process code, then look at it with Process Explorer. It may be a day or two before I get to it, though. If you get any other thoughts, let me know. It'd also be useful if you, or someone, could verify that the second argument doesn't happen under, say, 32 bit WinXP. That would clarify what the code should do to adapt to the different environment. (Of course, we couid just ask Microsoft... 8^) Don > > Mark > > >> As I mentioned before, this headache started when I tried to build the >> service on my new 64 bit Win 7 Pro machine (with 32 bit python and >> py2exe); I'd been developing and deploying the service successfully, >> with the same code, on my 32 bit Win XP machine for quite a while. I >> keep thinking that something must have changed in the environment to >> cause this... >> >> >> Fingers crossed, >> Don >> >>> >>> HTH, >>> >>> Mark >>>> I don''t know if I mentioned, but this is happening on a Windows 7 >>>> Professional OS, 64 bit (but with 32 bit Python 2.7 and py2exe). >>>> >>>> >>>> Hope this gives enough information to give you a clue... >>>> >>>> >>>> Don >>>> >>>>> HTH, >>>>> >>>>> Mark >>>>> >>>>>> Perhaps I should mention that I'm using a recent Activestate 2.7 >>>>>> distribution, which includes the win32 packages. >>>>>> >>>>>> Here's the setup.py: >>>>>>> from distutils.core import setup >>>>>>> import py2exe >>>>>>> import sys, os, shutil >>>>>>> >>>>>>> class Target: >>>>>>> def __init__(self, **kw): >>>>>>> self.__dict__.update(kw) >>>>>>> # for the versioninfo resources >>>>>>> self.version = "0.5.0" >>>>>>> self.company_name = "Advanced Publishing Technology" >>>>>>> self.copyright = "" >>>>>>> self.name = "Remote Client Access (RCA) Server" >>>>>>> >>>>>>> RCAservice = Target( >>>>>>> # Used for the versioninfo resource >>>>>>> description = "APT Circulation -- Remote Client Access Service", >>>>>>> # What to build. For a service, the module name (not the >>>>>>> # filename) must be specified! >>>>>>> modules = ["RCAServer"], >>>>>>> cmdline_style='pywin32', >>>>>>> ) >>>>>>> >>>>>>> setup( >>>>>>> service = [RCAservice], >>>>>>> options = {"py2exe": {"compressed": 1, >>>>>>> "optimize": 2, >>>>>>> "bundle_files": 1, >>>>>>> 'includes':['pyodbc', >>>>>>> 'twisted.web.resource', 'decimal', >>>>>>> # Needed for Python 2.5 lib -- >>>>>>> also the ignores below >>>>>>> 'email.utils', >>>>>>> 'email.base64mime', >>>>>>> 'email.generator', >>>>>>> 'email.iterators', >>>>>>> ], >>>>>>> 'packages': [# The following to allow SA to >>>>>>> find the MSSQL dialect >>>>>>> 'sqlalchemy.dialects', >>>>>>> ##'sqlalchemy.dialects.mssql', >>>>>>> ##'sqlalchemy.dialects.mssql.pyodbc', >>>>>>> ], >>>>>>> 'ignores':['FCNTL', 'OpenSSL', 'resource', >>>>>>> 'email.Utils', 'email.base64MIME', >>>>>>> 'email.Iterators', >>>>>>> 'email.Generator'], >>>>>>> 'dll_excludes': [ "mswsock.dll", >>>>>>> "powrprof.dll" ] >>>>>>> }}, >>>>>>> zipfile = None , >>>>>>> ) >>>>> ------------------------------------------------------------------------------ >>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >>>>> Get 100% visibility into your production application - at no cost. >>>>> Code-level diagnostics for performance bottlenecks with <2% overhead >>>>> Download for free and get started troubleshooting in minutes. >>>>> http://p.sf.net/sfu/appdyn_d2d_ap1 >>>> >>>> ------------------------------------------------------------------------------ >>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >>>> Get 100% visibility into your production application - at no cost. >>>> Code-level diagnostics for performance bottlenecks with <2% overhead >>>> Download for free and get started troubleshooting in minutes. >>>> http://p.sf.net/sfu/appdyn_d2d_ap1 >>>> _______________________________________________ >>>> Py2exe-users mailing list >>>> Py2...@li... >>>> https://lists.sourceforge.net/lists/listinfo/py2exe-users >>>> >>> ------------------------------------------------------------------------------ >>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >>> Get 100% visibility into your production application - at no cost. >>> Code-level diagnostics for performance bottlenecks with <2% overhead >>> Download for free and get started troubleshooting in minutes. >>> http://p.sf.net/sfu/appdyn_d2d_ap1 >> >> >> ------------------------------------------------------------------------------ >> Get 100% visibility into Java/.NET code with AppDynamics Lite >> It's a free troubleshooting tool designed for production >> Get down to code-level detail for bottlenecks, with <2% overhead. >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap2 >> >> >> >> _______________________________________________ >> Py2exe-users mailing list >> Py2...@li... >> https://lists.sourceforge.net/lists/listinfo/py2exe-users >> > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 |
From: Don D. <ddw...@ad...> - 2013-05-06 19:38:09
|
On 5/2/13 9:25 PM, Mark Hammond wrote: > On 3/05/2013 11:05 AM, Don Dwiggins wrote: > * So, in the second process, HandleCommandLine's initial setup code > winds up with "arg" = 'C:\\Dwig\\tmp\\TestRCA', which isn't > recognized as a command, so nothing gets done. > Right! What *should* be happening is that the service gets started with > no args, so RegisterServiceCtrlHandlerEx() gets called - this is what > isn't happening here. > ... > The second process will be created by the Service Control Manager, but I > too don't know where that second argument comes from - and almost > certainly it is the root cause of the problem. > > I'd be inclined to call this a bug in py2exe - it should probably just > attempt to start the service whenever the command-line isn't recognized, > rather than only when no args are specified. As an experiment, I changed the line in boot_service, in the "pywin32" branch to > if len(sys.argv) == 1 or '\\' in sys.argv[1]: ... and the service starts cleanly, and serves properly. > I'd love to know where that arg array comes from though - it may well be something specific to x64 Windows or just Windows 7. It would be interesting to know what sys.argv is from the service process when running the service via src - if it is exactly the same, then I'd infer it is just windows trying to be helpful or something :) Me too. I can write a workaround, possibly using the "custome" command line style and adding a HandleCommandLine adapted from win32serviceutil (to avoid relying on patched py2exe code), but it leaves me more than a little dissatisfied. I'll test deploying it on a 32 bit XP machine and a 64 bit Win 7 machine (other than my development machine); if it goes alright, I'll consider this thread closed, unless you or someone else has something to add. Thanks much for the help, -- Don Dwiggins Advanced Publishing Technology |
From: Don D. <ddw...@ad...> - 2013-05-23 15:39:34
|
On 5/6/13 12:37 PM, Don Dwiggins wrote: > On 5/2/13 9:25 PM, Mark Hammond wrote: >> I'd love to know where that arg array comes from though - it may well be something specific to x64 Windows or just Windows 7. It would be interesting to know what sys.argv is from the service process when running the service via src - if it is exactly the same, then I'd infer it is just windows trying to be helpful or something :) Here's a recap, based on what I've learned: First, the extra argument was caused by something I did quite a while ago: I added _exe_args_ to the service class attributes (I don't remember why). I'm not sure why this didn't cause problems right away, but, as our dialogue shows, it was a factor in the current situation. I'd recommend changing the py2exe/win32serviceutil code to ignore it, or to handle it properly when it's present. I don't need it for my service, though, so I've deleted it. My service depends on a set of configuration files located in the same folder as the service. Most of the problems I was having stemmed from my attempt to have the code, in various places, figure out where the service folder is. So, with cmdline_style='custom' in setup, I've rewritten it to have the module's HandleCommandLine (called from boot_service with no args) chdir to the executable's directory as soon as it's clear that the current process is the service process. Mark, thanks for the assistance, -- Don Dwiggins Advanced Publishing Technology |
From: Don D. <ddw...@ad...> - 2013-05-01 19:33:56
|
Mark, thanks for chiming in. > You might want to instrument your service so you can narrow down where > the failure is - eg, add your own lines to print to the event log or > to win32traceutil. I've been instrumenting win32serviceutuil, and have narrowed it down to the following line in ServiceFramework.__init__: > self.ssh = servicemanager.RegisterServiceCtrlHandler(args[0], > self.ServiceCtrlHandlerEx, True) This is after adding the following lines in HandleCommandLine's "start" code, right after the "try:" > global g_SvcInst > g_SvcInst = cls(serviceName) (This is definitely experimental -- I basically did in HandleCommandLine's "start" code what DebugService does. Again, before I did this, I was getting the "timeout" message.) The result, when running the executable with "start" is: > Error starting service: No error message is available I've instrumented it a bit further to get a traceback. This gives me: > Traceback (most recent call last): > File "win32serviceutil.pyo", line 735, in __init__ > error: (-1073741819, 'RegisterServiceCtrlHandlerEx', 'No error message > is available') > I assume you have tested your service without py2exe, so > win32serviceutil must be doing the right thing. Yes, it runs nicely from source, and also from the executable with "debug". > FWIW, > win32serviceutil's implementation of "start" just asks Windows to start > the service. That process ends up looking in the registry for the > executable specified for the named service and starting it. At this > point, pythonservice.exe is what is used (or a py2exe built exe in this > case), and it then also looks up the registry to find the classname, and > *it* instantiates the class. Thus, win32serviceutil's process is *not* > the service process - except in debug mode. This triggered a bit more exploration. I have both the source and the executable installed, under different service names. Comparing the registry entries, I note that the value for the subkey PythonClass is a full pathname for the source (ending in "RCAServer.RCAService", which is the module name and the service class name), but only "RCAServer.RCAService" for the executable. (I just experimented by making the value a full path, then trying "start" again -- didn't help, so I removed and reinstalled, which restored the value to what it was.) I don''t know if I mentioned, but this is happening on a Windows 7 Professional OS, 64 bit (but with 32 bit Python 2.7 and py2exe). Hope this gives enough information to give you a clue... Don > > HTH, > > Mark > >> Perhaps I should mention that I'm using a recent Activestate 2.7 >> distribution, which includes the win32 packages. >> >> Here's the setup.py: >>> from distutils.core import setup >>> import py2exe >>> import sys, os, shutil >>> >>> class Target: >>> def __init__(self, **kw): >>> self.__dict__.update(kw) >>> # for the versioninfo resources >>> self.version = "0.5.0" >>> self.company_name = "Advanced Publishing Technology" >>> self.copyright = "" >>> self.name = "Remote Client Access (RCA) Server" >>> >>> RCAservice = Target( >>> # Used for the versioninfo resource >>> description = "APT Circulation -- Remote Client Access Service", >>> # What to build. For a service, the module name (not the >>> # filename) must be specified! >>> modules = ["RCAServer"], >>> cmdline_style='pywin32', >>> ) >>> >>> setup( >>> service = [RCAservice], >>> options = {"py2exe": {"compressed": 1, >>> "optimize": 2, >>> "bundle_files": 1, >>> 'includes':['pyodbc', >>> 'twisted.web.resource', 'decimal', >>> # Needed for Python 2.5 lib -- >>> also the ignores below >>> 'email.utils', >>> 'email.base64mime', >>> 'email.generator', >>> 'email.iterators', >>> ], >>> 'packages': [# The following to allow SA to >>> find the MSSQL dialect >>> 'sqlalchemy.dialects', >>> ##'sqlalchemy.dialects.mssql', >>> ##'sqlalchemy.dialects.mssql.pyodbc', >>> ], >>> 'ignores':['FCNTL', 'OpenSSL', 'resource', >>> 'email.Utils', 'email.base64MIME', >>> 'email.Iterators', >>> 'email.Generator'], >>> 'dll_excludes': [ "mswsock.dll", >>> "powrprof.dll" ] >>> }}, >>> zipfile = None , >>> ) > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 |
From: Mark H. <ski...@gm...> - 2013-05-01 23:52:55
|
On 2/05/2013 5:33 AM, Don Dwiggins wrote: > Mark, thanks for chiming in. > >> You might want to instrument your service so you can narrow down where >> the failure is - eg, add your own lines to print to the event log or >> to win32traceutil. > > I've been instrumenting win32serviceutuil, and have narrowed it down to > the following line in ServiceFramework.__init__: >> self.ssh = servicemanager.RegisterServiceCtrlHandler(args[0], >> self.ServiceCtrlHandlerEx, True) > This is after adding the following lines in HandleCommandLine's "start" > code, right after the "try:" >> global g_SvcInst >> g_SvcInst = cls(serviceName) > (This is definitely experimental -- I basically did in > HandleCommandLine's "start" code what DebugService does. Again, before > I did this, I was getting the "timeout" message.) Right - an error here would be expected as you are trying to call RegisterServiceCtrlHandler() in a process that isn't being started as a service. What does your instrumentation say happens without those additional lines? ... > This triggered a bit more exploration. > > I have both the source and the executable installed, under different > service names. Comparing the registry entries, I note that the value > for the subkey PythonClass is a full pathname for the source (ending in > "RCAServer.RCAService", which is the module name and the service class > name), but only "RCAServer.RCAService" for the executable. > (I just experimented by making the value a full path, then trying > "start" again -- didn't help, so I removed and reinstalled, which > restored the value to what it was.) This *should* be OK - in a py2exe generated service, the module name alone is (or should be) guaranteed to be importable, but for a "source" service it might not already be on sys.path, so a full path name is supported - you will find all this magic in boot_service.py (see below). I'd also experiment with the bundle_files option. Also note that service support is implements mainly via py2exe/boot_service.py, so if instrumenting your service code seems to show your module never being loaded, try instrumenting that file and rebuilding to see what it tells you. HTH, Mark > > I don''t know if I mentioned, but this is happening on a Windows 7 > Professional OS, 64 bit (but with 32 bit Python 2.7 and py2exe). > > > Hope this gives enough information to give you a clue... > > > Don > >> >> HTH, >> >> Mark >> >>> Perhaps I should mention that I'm using a recent Activestate 2.7 >>> distribution, which includes the win32 packages. >>> >>> Here's the setup.py: >>>> from distutils.core import setup >>>> import py2exe >>>> import sys, os, shutil >>>> >>>> class Target: >>>> def __init__(self, **kw): >>>> self.__dict__.update(kw) >>>> # for the versioninfo resources >>>> self.version = "0.5.0" >>>> self.company_name = "Advanced Publishing Technology" >>>> self.copyright = "" >>>> self.name = "Remote Client Access (RCA) Server" >>>> >>>> RCAservice = Target( >>>> # Used for the versioninfo resource >>>> description = "APT Circulation -- Remote Client Access Service", >>>> # What to build. For a service, the module name (not the >>>> # filename) must be specified! >>>> modules = ["RCAServer"], >>>> cmdline_style='pywin32', >>>> ) >>>> >>>> setup( >>>> service = [RCAservice], >>>> options = {"py2exe": {"compressed": 1, >>>> "optimize": 2, >>>> "bundle_files": 1, >>>> 'includes':['pyodbc', >>>> 'twisted.web.resource', 'decimal', >>>> # Needed for Python 2.5 lib -- >>>> also the ignores below >>>> 'email.utils', >>>> 'email.base64mime', >>>> 'email.generator', >>>> 'email.iterators', >>>> ], >>>> 'packages': [# The following to allow SA to >>>> find the MSSQL dialect >>>> 'sqlalchemy.dialects', >>>> ##'sqlalchemy.dialects.mssql', >>>> ##'sqlalchemy.dialects.mssql.pyodbc', >>>> ], >>>> 'ignores':['FCNTL', 'OpenSSL', 'resource', >>>> 'email.Utils', 'email.base64MIME', >>>> 'email.Iterators', >>>> 'email.Generator'], >>>> 'dll_excludes': [ "mswsock.dll", >>>> "powrprof.dll" ] >>>> }}, >>>> zipfile = None , >>>> ) >> >> ------------------------------------------------------------------------------ >> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >> Get 100% visibility into your production application - at no cost. >> Code-level diagnostics for performance bottlenecks with <2% overhead >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap1 > > > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Py2exe-users mailing list > Py2...@li... > https://lists.sourceforge.net/lists/listinfo/py2exe-users > |
From: Mark H. <ski...@gm...> - 2013-05-02 00:56:28
|
I don't think this is your problem, but it's worth mentioning - you can't simply run the py2exe generated program to have it run as a service. You must run it with a "start" param, or start it directly via Windows (obviously after registering it). Running it without any args means it assumes it is being run directly by the service control manager and will fail - but IIRC, it will fail in a slightly different way - more like how it fails in your instrumented version (ie, with RegisterServiceCtrlHandlerEx failing) Mark On 2/05/2013 9:52 AM, Mark Hammond wrote: > On 2/05/2013 5:33 AM, Don Dwiggins wrote: >> Mark, thanks for chiming in. >> >>> You might want to instrument your service so you can narrow down where >>> the failure is - eg, add your own lines to print to the event log or >>> to win32traceutil. >> >> I've been instrumenting win32serviceutuil, and have narrowed it down to >> the following line in ServiceFramework.__init__: >>> self.ssh = servicemanager.RegisterServiceCtrlHandler(args[0], >>> self.ServiceCtrlHandlerEx, True) >> This is after adding the following lines in HandleCommandLine's "start" >> code, right after the "try:" >>> global g_SvcInst >>> g_SvcInst = cls(serviceName) >> (This is definitely experimental -- I basically did in >> HandleCommandLine's "start" code what DebugService does. Again, before >> I did this, I was getting the "timeout" message.) > > Right - an error here would be expected as you are trying to call > RegisterServiceCtrlHandler() in a process that isn't being started as a > service. > > What does your instrumentation say happens without those additional lines? > > ... > >> This triggered a bit more exploration. >> >> I have both the source and the executable installed, under different >> service names. Comparing the registry entries, I note that the value >> for the subkey PythonClass is a full pathname for the source (ending in >> "RCAServer.RCAService", which is the module name and the service class >> name), but only "RCAServer.RCAService" for the executable. >> (I just experimented by making the value a full path, then trying >> "start" again -- didn't help, so I removed and reinstalled, which >> restored the value to what it was.) > > This *should* be OK - in a py2exe generated service, the module name > alone is (or should be) guaranteed to be importable, but for a "source" > service it might not already be on sys.path, so a full path name is > supported - you will find all this magic in boot_service.py (see below). > > I'd also experiment with the bundle_files option. > > Also note that service support is implements mainly via > py2exe/boot_service.py, so if instrumenting your service code seems to > show your module never being loaded, try instrumenting that file and > rebuilding to see what it tells you. > > HTH, > > Mark >> >> I don''t know if I mentioned, but this is happening on a Windows 7 >> Professional OS, 64 bit (but with 32 bit Python 2.7 and py2exe). >> >> >> Hope this gives enough information to give you a clue... >> >> >> Don >> >>> >>> HTH, >>> >>> Mark >>> >>>> Perhaps I should mention that I'm using a recent Activestate 2.7 >>>> distribution, which includes the win32 packages. >>>> >>>> Here's the setup.py: >>>>> from distutils.core import setup >>>>> import py2exe >>>>> import sys, os, shutil >>>>> >>>>> class Target: >>>>> def __init__(self, **kw): >>>>> self.__dict__.update(kw) >>>>> # for the versioninfo resources >>>>> self.version = "0.5.0" >>>>> self.company_name = "Advanced Publishing Technology" >>>>> self.copyright = "" >>>>> self.name = "Remote Client Access (RCA) Server" >>>>> >>>>> RCAservice = Target( >>>>> # Used for the versioninfo resource >>>>> description = "APT Circulation -- Remote Client Access >>>>> Service", >>>>> # What to build. For a service, the module name (not the >>>>> # filename) must be specified! >>>>> modules = ["RCAServer"], >>>>> cmdline_style='pywin32', >>>>> ) >>>>> >>>>> setup( >>>>> service = [RCAservice], >>>>> options = {"py2exe": {"compressed": 1, >>>>> "optimize": 2, >>>>> "bundle_files": 1, >>>>> 'includes':['pyodbc', >>>>> 'twisted.web.resource', 'decimal', >>>>> # Needed for Python 2.5 >>>>> lib -- >>>>> also the ignores below >>>>> 'email.utils', >>>>> 'email.base64mime', >>>>> 'email.generator', >>>>> 'email.iterators', >>>>> ], >>>>> 'packages': [# The following to allow >>>>> SA to >>>>> find the MSSQL dialect >>>>> 'sqlalchemy.dialects', >>>>> ##'sqlalchemy.dialects.mssql', >>>>> ##'sqlalchemy.dialects.mssql.pyodbc', >>>>> ], >>>>> 'ignores':['FCNTL', 'OpenSSL', >>>>> 'resource', >>>>> 'email.Utils', >>>>> 'email.base64MIME', >>>>> 'email.Iterators', >>>>> 'email.Generator'], >>>>> 'dll_excludes': [ "mswsock.dll", >>>>> "powrprof.dll" ] >>>>> }}, >>>>> zipfile = None , >>>>> ) >>> >>> ------------------------------------------------------------------------------ >>> >>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >>> Get 100% visibility into your production application - at no cost. >>> Code-level diagnostics for performance bottlenecks with <2% overhead >>> Download for free and get started troubleshooting in minutes. >>> http://p.sf.net/sfu/appdyn_d2d_ap1 >> >> >> >> ------------------------------------------------------------------------------ >> >> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >> Get 100% visibility into your production application - at no cost. >> Code-level diagnostics for performance bottlenecks with <2% overhead >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap1 >> _______________________________________________ >> Py2exe-users mailing list >> Py2...@li... >> https://lists.sourceforge.net/lists/listinfo/py2exe-users >> > |
From: Don D. <ddw...@ad...> - 2013-05-03 00:23:02
|
On 5/1/13 5:56 PM, Mark Hammond wrote: > I don't think this is your problem, but it's worth mentioning - you > can't simply run the py2exe generated program to have it run as a > service. You must run it with a "start" param, or start it directly via > Windows (obviously after registering it). Running it without any args > means it assumes it is being run directly by the service control manager > and will fail - but IIRC, it will fail in a slightly different way - > more like how it fails in your instrumented version (ie, with > RegisterServiceCtrlHandlerEx failing) Right, I knew this, and have been using the "start" param to the executable (and "install" and "remove" where appropriate). Don > > Mark > > On 2/05/2013 9:52 AM, Mark Hammond wrote: >> On 2/05/2013 5:33 AM, Don Dwiggins wrote: >>> Mark, thanks for chiming in. >>> >>>> You might want to instrument your service so you can narrow down where >>>> the failure is - eg, add your own lines to print to the event log or >>>> to win32traceutil. >>> I've been instrumenting win32serviceutuil, and have narrowed it down to >>> the following line in ServiceFramework.__init__: >>>> self.ssh = servicemanager.RegisterServiceCtrlHandler(args[0], >>>> self.ServiceCtrlHandlerEx, True) >>> This is after adding the following lines in HandleCommandLine's "start" >>> code, right after the "try:" >>>> global g_SvcInst >>>> g_SvcInst = cls(serviceName) >>> (This is definitely experimental -- I basically did in >>> HandleCommandLine's "start" code what DebugService does. Again, before >>> I did this, I was getting the "timeout" message.) >> Right - an error here would be expected as you are trying to call >> RegisterServiceCtrlHandler() in a process that isn't being started as a >> service. >> >> What does your instrumentation say happens without those additional lines? >> >> ... >> >>> This triggered a bit more exploration. >>> >>> I have both the source and the executable installed, under different >>> service names. Comparing the registry entries, I note that the value >>> for the subkey PythonClass is a full pathname for the source (ending in >>> "RCAServer.RCAService", which is the module name and the service class >>> name), but only "RCAServer.RCAService" for the executable. >>> (I just experimented by making the value a full path, then trying >>> "start" again -- didn't help, so I removed and reinstalled, which >>> restored the value to what it was.) >> This *should* be OK - in a py2exe generated service, the module name >> alone is (or should be) guaranteed to be importable, but for a "source" >> service it might not already be on sys.path, so a full path name is >> supported - you will find all this magic in boot_service.py (see below). >> >> I'd also experiment with the bundle_files option. >> >> Also note that service support is implements mainly via >> py2exe/boot_service.py, so if instrumenting your service code seems to >> show your module never being loaded, try instrumenting that file and >> rebuilding to see what it tells you. >> >> HTH, >> >> Mark >>> I don''t know if I mentioned, but this is happening on a Windows 7 >>> Professional OS, 64 bit (but with 32 bit Python 2.7 and py2exe). >>> >>> >>> Hope this gives enough information to give you a clue... >>> >>> >>> Don >>> >>>> HTH, >>>> >>>> Mark >>>> >>>>> Perhaps I should mention that I'm using a recent Activestate 2.7 >>>>> distribution, which includes the win32 packages. >>>>> >>>>> Here's the setup.py: >>>>>> from distutils.core import setup >>>>>> import py2exe >>>>>> import sys, os, shutil >>>>>> >>>>>> class Target: >>>>>> def __init__(self, **kw): >>>>>> self.__dict__.update(kw) >>>>>> # for the versioninfo resources >>>>>> self.version = "0.5.0" >>>>>> self.company_name = "Advanced Publishing Technology" >>>>>> self.copyright = "" >>>>>> self.name = "Remote Client Access (RCA) Server" >>>>>> >>>>>> RCAservice = Target( >>>>>> # Used for the versioninfo resource >>>>>> description = "APT Circulation -- Remote Client Access >>>>>> Service", >>>>>> # What to build. For a service, the module name (not the >>>>>> # filename) must be specified! >>>>>> modules = ["RCAServer"], >>>>>> cmdline_style='pywin32', >>>>>> ) >>>>>> >>>>>> setup( >>>>>> service = [RCAservice], >>>>>> options = {"py2exe": {"compressed": 1, >>>>>> "optimize": 2, >>>>>> "bundle_files": 1, >>>>>> 'includes':['pyodbc', >>>>>> 'twisted.web.resource', 'decimal', >>>>>> # Needed for Python 2.5 >>>>>> lib -- >>>>>> also the ignores below >>>>>> 'email.utils', >>>>>> 'email.base64mime', >>>>>> 'email.generator', >>>>>> 'email.iterators', >>>>>> ], >>>>>> 'packages': [# The following to allow >>>>>> SA to >>>>>> find the MSSQL dialect >>>>>> 'sqlalchemy.dialects', >>>>>> ##'sqlalchemy.dialects.mssql', >>>>>> ##'sqlalchemy.dialects.mssql.pyodbc', >>>>>> ], >>>>>> 'ignores':['FCNTL', 'OpenSSL', >>>>>> 'resource', >>>>>> 'email.Utils', >>>>>> 'email.base64MIME', >>>>>> 'email.Iterators', >>>>>> 'email.Generator'], >>>>>> 'dll_excludes': [ "mswsock.dll", >>>>>> "powrprof.dll" ] >>>>>> }}, >>>>>> zipfile = None , >>>>>> ) >>>> ------------------------------------------------------------------------------ >>>> >>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >>>> Get 100% visibility into your production application - at no cost. >>>> Code-level diagnostics for performance bottlenecks with <2% overhead >>>> Download for free and get started troubleshooting in minutes. >>>> http://p.sf.net/sfu/appdyn_d2d_ap1 >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >>> Get 100% visibility into your production application - at no cost. >>> Code-level diagnostics for performance bottlenecks with <2% overhead >>> Download for free and get started troubleshooting in minutes. >>> http://p.sf.net/sfu/appdyn_d2d_ap1 >>> _______________________________________________ >>> Py2exe-users mailing list >>> Py2...@li... >>> https://lists.sourceforge.net/lists/listinfo/py2exe-users >>> > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 |