I have been able to build and distribute wxPython Classic applications using Py2exe (Windows) and Py2app (OS X) and allow them to update themselves using Esky that is integrated into wx via the wx.lib.SoftwareUpdate mixin class.
Unfortunately there are issues using Py2exe with wxPython 4 and Python 3 and there was an announcement by Tomas Heller, its author that it is no longer going to be maintained by him https://sourceforge.net/p/py2exe/mailman/message/36033869/
Similarly there are also Esky/Python 3 problems. There has been no activity at https://github.com/cloudmatrix/esky for the past year or two and co-incidentally(?) I received a message from Ryan Kelly yesterday saying that an issue I raised in October 2016 was being closed as the project is no longer maintained.
I have made initial attempts to use these with my Dietplan7 application that has been migrated to wxPython 4 and Python 3 and come across several problems so far. Some are not wxPython related but some, such as importing wx.lib.pubsub and discovering libcairo-2.dll, I think I can work round but is this the way I should be going?
I had been using py2exe on Windows with Py2 for about 12 years, and just recently converted to PyInstaller. It cleaned up a bunch of hacky things I had to do with py2exe to get the right DLLs and so on, I was pleased with that. (Plus the fact that PyInstaller has active development, they’ve got support for 3.6, whereas py2exe was two years behind getting 3.5 support and that’s the current version.)
One rough spot that I haven’t resolved yet is figuring out if the resulting .exe was built as a console or windows app at application startup. In py2exe the sys.frozen values were “console_exe” and “windows_exe”, respectively, but PyInstaller sets sys.frozen to True, so that bit of information is missing. (I use this to redirect sys.stdout/err prior to startup of the application’s main so if there is an error, I can log it to a file and tell the end user to email it to me. If you don’t care about this, then this is probably a non-issue for you.)
Eric
···
On Monday, February 26, 2018 at 8:12:08 AM UTC-8, David Hughes wrote:
I have been able to build and distribute wxPython Classic applications using Py2exe (Windows) and Py2app (OS X) and allow them to update themselves using Esky that is integrated into wx via the wx.lib.SoftwareUpdate mixin class.
Unfortunately there are issues using Py2exe with wxPython 4 and Python 3 and there was an announcement by Tomas Heller, its author that it is no longer going to be maintained by him https://sourceforge.net/p/py2exe/mailman/message/36033869/
Similarly there are also Esky/Python 3 problems. There has been no activity at https://github.com/cloudmatrix/esky for the past year or two and co-incidentally(?) I received a message from Ryan Kelly yesterday saying that an issue I raised in October 2016 was being closed as the project is no longer maintained.
I have made initial attempts to use these with my Dietplan7 application that has been migrated to wxPython 4 and Python 3 and come across several problems so far. Some are not wxPython related but some, such as importing wx.lib.pubsub and discovering libcairo-2.dll, I think I can work round but is this the way I should be going?
You might also consider using conda constructor with Anaconda Python. This creates single-file installers (shell scripts for Linux and MacOSX, exe for Windows) that installs a full Anaconda environment with specified packages and scripts. This means a really simple build configuration file, but does also allow “post install” scripts. I use the post-install scripts to make a selection of clickable Desktop shortcuts (Windows) or trivial Apps (Mac OSX) for launching several wxPython GUIs for one of my projects. By providing a full Anaconda environment, updates at the user end are as simple as running “conda update”, which could probably be done automatically or by prompting the user, though I don’t know of a tool like esky for that.
I’ve struggled with py2exe and py2app in the past, and find conda constructor to be much less work to maintain.
I have been able to build and distribute wxPython Classic applications using Py2exe (Windows) and Py2app (OS X) and allow them to update themselves using Esky that is integrated into wx via the wx.lib.SoftwareUpdate mixin class.
Unfortunately there are issues using Py2exe with wxPython 4 and Python 3 and there was an announcement by Tomas Heller, its author that it is no longer going to be maintained by him https://sourceforge.net/p/py2exe/mailman/message/36033869/
Similarly there are also Esky/Python 3 problems. There has been no activity at https://github.com/cloudmatrix/esky for the past year or two and co-incidentally(?) I received a message from Ryan Kelly yesterday saying that an issue I raised in October 2016 was being closed as the project is no longer maintained.
I have made initial attempts to use these with my Dietplan7 application that has been migrated to wxPython 4 and Python 3 and come across several problems so far. Some are not wxPython related but some, such as importing wx.lib.pubsub and discovering libcairo-2.dll, I think I can work round but is this the way I should be going?
David Hughes
Forestfield Software
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
I also moved from Py2app to PyInstaller when I was playing around with Phoenix and I haven’t looked back since.
I always wanted a packager that would work with macos, windows and linux. PyInstaller has been the answer for me.
The only thing I had to work around was storing of data files (e.g. bitmap images). There’s a little bit funky code that needs to be incorporated to determined where the files live in the frozen app bundle. I didn’t have to do that with Py2app, but once I sorted that out I was happy with PyInstaller (especially since I plan to ditch wxpython 2.8/3.0 and go solely wxpython 4 aka Phoenix).
Brendan.
···
On Tuesday, 27 February 2018 03:12:08 UTC+11, David Hughes wrote:
I have been able to build and distribute wxPython Classic applications using Py2exe (Windows) and Py2app (OS X) and allow them to update themselves using Esky that is integrated into wx via the wx.lib.SoftwareUpdate mixin class.
Unfortunately there are issues using Py2exe with wxPython 4 and Python 3 and there was an announcement by Tomas Heller, its author that it is no longer going to be maintained by him https://sourceforge.net/p/py2exe/mailman/message/36033869/
Similarly there are also Esky/Python 3 problems. There has been no activity at https://github.com/cloudmatrix/esky for the past year or two and co-incidentally(?) I received a message from Ryan Kelly yesterday saying that an issue I raised in October 2016 was being closed as the project is no longer maintained.
I have made initial attempts to use these with my Dietplan7 application that has been migrated to wxPython 4 and Python 3 and come across several problems so far. Some are not wxPython related but some, such as importing wx.lib.pubsub and discovering libcairo-2.dll, I think I can work round but is this the way I should be going?
I also moved from Py2app to PyInstaller when I was playing around with Phoenix and I haven’t looked back since.
I always wanted a packager that would work with macos, windows and linux. PyInstaller has been the answer for me.
The only thing I had to work around was storing of data files (e.g. bitmap images). There’s a little bit funky code that needs to be incorporated to determined where the files live in the frozen app bundle. I didn’t have to do that with Py2app, but once I sorted that out I was happy with PyInstaller (especially since I plan to ditch wxpython 2.8/3.0 and go solely wxpython 4 aka Phoenix).
Brendan.
On Tuesday, 27 February 2018 03:12:08 UTC+11, David Hughes wrote:
I have been able to build and distribute wxPython Classic applications using Py2exe (Windows) and Py2app (OS X) and allow them to update themselves using Esky that is integrated into wx via the wx.lib.SoftwareUpdate mixin class.
Unfortunately there are issues using Py2exe with wxPython 4 and Python 3 and there was an announcement by Tomas Heller, its author that it is no longer going to be maintained by him https://sourceforge.net/p/py2exe/mailman/message/36033869/
Similarly there are also Esky/Python 3 problems. There has been no activity at https://github.com/cloudmatrix/esky for the past year or two and co-incidentally(?) I received a message from Ryan Kelly yesterday saying that an issue I raised in October 2016 was being closed as the project is no longer maintained.
I have made initial attempts to use these with my Dietplan7 application that has been migrated to wxPython 4 and Python 3 and come across several problems so far. Some are not wxPython related but some, such as importing wx.lib.pubsub and discovering libcairo-2.dll, I think I can work round but is this the way I should be going?
David Hughes
Forestfield Software
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
I always wanted a packager that would work with macos, windows and linux. PyInstaller has been the answer for me.
The only thing I had to work around was storing of data files (e.g. bitmap images). There's a little bit funky code that needs to be incorporated to determined where the files live in the frozen app bundle. I didn't have to do that with Py2app, but once I sorted that out I was happy with PyInstaller (especially since I plan to ditch wxpython 2.8/3.0 and go solely wxpython 4 aka Phoenix).
On Tuesday, 27 February 2018 03:12:08 UTC+11, David Hughes wrote:
I have been able to build and distribute wxPython Classic applications using Py2exe (Windows) and Py2app (OS X) and allow them to update themselves using Esky that is integrated into wx via the wx.lib.SoftwareUpdate mixin class.
I have made initial attempts to use these with my Dietplan7 application that has been migrated to wxPython 4 and Python 3 and come across several problems so far. Some are not wxPython related but some, such as importing wx.lib.pubsub and discovering libcairo-2.dll, I think I can work round but is this the way I should be going?
One option for creating a mac installer is to use a VM - a really good set of instructions for doing so, (not aimed specifically at python), can be found at https://www.pcsteps.com/2157-mac-os-x-virtual-machine-vmware-player/ but there are also some online options such as Travis CI & BuildKite.