I compiled my Python app for OSX using py2app. The package is 102.8MB. When I check the Contents folder the two biggest files are the libwx_osx_cocoau-2.9.3.0.0.dylib (53.5MB) in the Frameworks folder and the wx folder (26.2MB) in Resources/lib/python2.7/lib-dynload.
1. Strip the binaries (add strip=True to py2app options)
2. "Thin" the universal binaries if you don't need to support multiple binary formats with lipo
You would need to write a little script to recursively go though your *.app and execute something like the following command for every file with a "so" or "dynlib" extension.
On Mon, 09 Apr 2012 23:24:02 +0200, sbaechler <stbaechler@gmail.com> wrote:
I compiled my Python app for OSX using py2app. The package is 102.8MB. When
I check the Contents folder the two biggest files are
the libwx_osx_cocoau-2.9.3.0.0.dylib (53.5MB) in the Frameworks folder and
the wx folder (26.2MB) in Resources/lib/python2.7/lib-dynload.
I was considering buying a Mac for my wife (and surreptitiously
stealing it from time to time) to finally be able to test few things
on this funny platform - I mean, if I am ever able to make wxPython
run on it.
On Windows 7 64 bit, with Python 2.7 64 bit, with no effort at
filtering out unneeded stuff I get to around 15 MB of stuff with
py2exe.
And for the rant moment: damn the little info available for py2exe on
64 bit Python (and no possibility of making a single-file executable
anyway on any platform). But it doesn't matter, I am almost completely
sold to PyInstaller, although it is much less intuitive than py2exe. I
am not holding my breath for a new release of py2exe any time soon, as
0.6.9 was released something like 15 years ago...
What I'd like to see is a "Hello, World" application, before and after, in
terms of MB, on Mac.
+Inf
I was considering buying a Mac for my wife (and surreptitiously
stealing it from time to time) to finally be able to test few things
on this funny platform - I mean, if I am ever able to make wxPython
run on it.
Try it, you'll like it! And wxPython does work well.
This is an odd issue -- "Universal" binaries do make app bundles twice
as big as thy might otherwise be -- but as noted, they can be stripped
and we wont need to continue to support PPC for long (32+64 bit?
maybe...)
But this really isn't much of an issue these days -- there are some
folks with limited bandwidth that may suffer, but otherwise, "size
doesn't matter"
-Chris
···
On Windows 7 64 bit, with Python 2.7 64 bit, with no effort at
filtering out unneeded stuff I get to around 15 MB of stuff with
py2exe.
And for the rant moment: damn the little info available for py2exe on
64 bit Python (and no possibility of making a single-file executable
anyway on any platform). But it doesn't matter, I am almost completely
sold to PyInstaller, although it is much less intuitive than py2exe. I
am not holding my breath for a new release of py2exe any time soon, as
0.6.9 was released something like 15 years ago...
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Well, size might not be as important as before, but I think it’s a bit hard to ‘sell’ your app
(even if it’s free) when the Windows binary has 10MB and the Mac on has 100MB…
···
–
Prof. Carlos Henrique Grohmann
Institute of Geosciences - Univ. of São Paulo, Brazil
Tell that to our customers back in the Oil Regions: last year I had to
ship in a rush a custom-made GUI for reservoir simulation analysis,
built with wx, numpy, matplotlib and a bit of Fortran/f2py to read
input files faster. Luckily enough for me, PyInstaller was able to
shrink it down to 17 MB and I was able to send it by e-mail. If I get
a 100 MB app out of that, I need FedEx (or its European equivalent) to
ship a CD overnight or rely on a shaky 5,000-Km slow-bandwidth
connection over the network.
What I'd like to see is a "Hello, World" application, before and after, in
terms of MB, on Mac.
+Inf
I was considering buying a Mac for my wife (and surreptitiously
stealing it from time to time) to finally be able to test few things
on this funny platform - I mean, if I am ever able to make wxPython
run on it.
Try it, you'll like it! And wxPython does work well.
This is an odd issue -- "Universal" binaries do make app bundles twice
as big as thy might otherwise be -- but as noted, they can be stripped
and we wont need to continue to support PPC for long (32+64 bit?
maybe...)
But this really isn't much of an issue these days -- there are some
folks with limited bandwidth that may suffer, but otherwise, "size
doesn't matter"
One time I tried this the resulting app went from being around 100mb to
around 30mb with stripping and thinning.
What I'd like to see is a "Hello, World" application, before and after, in
terms of MB, on Mac.
+Inf
I was considering buying a Mac for my wife (and surreptitiously
stealing it from time to time) to finally be able to test few things
on this funny platform - I mean, if I am ever able to make wxPython
run on it.
Out of curiosity, what do you mean by this? It's download the installer and run it, whether you're on Windows or Mac. The only issue that complicates things is Python itself, which is a bit of a mess thanks to Tkinter not having 64-bit support for 10.5. And Python could have avoided that whole mess by just bundling a better updated toolkit like wxPython instead.
Kevin
···
On Apr 10, 2012, at 12:23 PM, Andrea Gavana wrote:
On 10 April 2012 20:56, C M wrote:
On Windows 7 64 bit, with Python 2.7 64 bit, with no effort at
filtering out unneeded stuff I get to around 15 MB of stuff with
py2exe.
And for the rant moment: damn the little info available for py2exe on
64 bit Python (and no possibility of making a single-file executable
anyway on any platform). But it doesn't matter, I am almost completely
sold to PyInstaller, although it is much less intuitive than py2exe. I
am not holding my breath for a new release of py2exe any time soon, as
0.6.9 was released something like 15 years ago...
No problem, although a PyInstaller setup file (i.e., a *.spec file)
will not be of any help in general and will not give any useful
insight about what's included in an app, unless you heavily tweak and
customize it.
I couldn't use py2exe because it doesn't allow to build single-file
apps anymore, at least when third-party libraries (i.e., wxPython,
numpy, matplotlib, etc...) are needed.
The attached PyInstaller setup script did everything for me, finding
the various dlls/pyds needed (included my custom one, made with f2py)
and shrank it to 17 MB (although I used upx compression).
One time I tried this the resulting app went from being around 100mb to
around 30mb with stripping and thinning.
What I'd like to see is a "Hello, World" application, before and after, in
terms of MB, on Mac.
+Inf
I was considering buying a Mac for my wife (and surreptitiously
stealing it from time to time) to finally be able to test few things
on this funny platform - I mean, if I am ever able to make wxPython
run on it.
Out of curiosity, what do you mean by this? It's download the installer and run it, whether you're on Windows or Mac. The only issue that complicates things is Python itself, which is a bit of a mess thanks to Tkinter not having 64-bit support for 10.5. And Python could have avoided that whole mess by just bundling a better updated toolkit like wxPython instead.
Uh, nothing against Mac, I was just thinking about how useless I would
be with a completely new OS and to the fact that I would screw up
something in any case.
Other than that, once upon a time I wished wxPython were the official
GUI framework for Python. Now I am convinced that it is so much better
the way it is now. Python release schedule is awfully out of sync with
the wx one, not to mention that a tremendous effort from the
developers was/is needed for the port to Python 3 (which is not ready
yet), just because now "print is a function".
One time I tried this the resulting app went from being around 100mb to
around 30mb with stripping and thinning.
What I'd like to see is a "Hello, World" application, before and after, in
terms of MB, on Mac.
+Inf
I was considering buying a Mac for my wife (and surreptitiously
stealing it from time to time) to finally be able to test few things
on this funny platform - I mean, if I am ever able to make wxPython
run on it.
Out of curiosity, what do you mean by this? It's download the installer and run it, whether you're on Windows or Mac. The only issue that complicates things is Python itself, which is a bit of a mess thanks to Tkinter not having 64-bit support for 10.5. And Python could have avoided that whole mess by just bundling a better updated toolkit like wxPython instead.
Uh, nothing against Mac, I was just thinking about how useless I would
be with a completely new OS and to the fact that I would screw up
something in any case.
I think you'll find it not so different from Linux if you're using terminal, and Windows if you're using GUI. (aside from the obvious window management button placement and keyboard shortcut 'retraining' issues)
Other than that, once upon a time I wished wxPython were the official
GUI framework for Python. Now I am convinced that it is so much better
the way it is now. Python release schedule is awfully out of sync with
the wx one, not to mention that a tremendous effort from the
developers was/is needed for the port to Python 3 (which is not ready
yet), just because now "print is a function".
Great.
At least for the common cases, print("Hello World!") works in Python 2.x too. (You're just printing a tuple with a string in it there.) So many of the print changes needed could run under 2 and 3 without problems. I think module imports would probably be one of the biggest issues to deal with.
At least part of the wxPython delays with py3 are actually caused by doing Phoenix at the same time, so that we get leaner bindings, faster loading, etc. all at the same time. We could have done a SWIG hack for Py 3, it would just have delayed Phoenix. And really, the big conversion work that needs done is wx.lib, which could be worked on at any time by some adventurous hackers willing to do some 2to3 conversions, work out any conditional code needed for 2 and 3 support to co-exist, and posting patches. I really wish I had more time to hack on wxPy stuff, Py 3 is about the first thing (after a Win build bot) that I'd start hacking on.
Regards,
Kevin
···
On Apr 10, 2012, at 1:12 PM, Andrea Gavana wrote:
On 10 April 2012 22:04, Kevin Ollivier wrote:
On Apr 10, 2012, at 12:23 PM, Andrea Gavana wrote:
One time I tried this the resulting app went from being around 100mb to
around 30mb with stripping and thinning.
What I'd like to see is a "Hello, World" application, before and after, in
terms of MB, on Mac.
+Inf
I was considering buying a Mac for my wife (and surreptitiously
stealing it from time to time) to finally be able to test few things
on this funny platform - I mean, if I am ever able to make wxPython
run on it.
Other than that, once upon a time I wished wxPython were the official
GUI framework for Python. Now I am convinced that it is so much better
the way it is now. Python release schedule is awfully out of sync with
the wx one, not to mention that a tremendous effort from the
developers was/is needed for the port to Python 3 (which is not ready
yet), just because now "print is a function".
Great.
At least for the common cases, print("Hello World!") works in Python 2.x too. (You're just printing a tuple with a string in it there.) So many of the print changes needed could run under 2 and 3 without problems. I think module imports would probably be one of the biggest issues to deal with.
I know, it was just an exaggeration; my point was, the Python 3 port
is a whole lot of work for C extensions with a very small gain. I
would rant much less if bolder moves were made during the inception of
Python 3 (but not like Perl 6).
At least part of the wxPython delays with py3 are actually caused by doing Phoenix at the same time, so that we get leaner bindings, faster loading, etc. all at the same time. We could have done a SWIG hack for Py 3, it would just have delayed Phoenix. And really, the big conversion work that needs done is wx.lib, which could be worked on at any time by some adventurous hackers willing to do some 2to3 conversions, work out any conditional code needed for 2 and 3 support to co-exist, and posting patches. I really wish I had more time to hack on wxPy stuff, Py 3 is about the first thing (after a Win build bot) that I'd start hacking on.
As far as I remember (but I may be wrong), Amaury was maintaining a
set of 2to3 patched things for wxPython, including wx.lib (but my
memory may fail me here...).
The 2to3 conversion per se is relatively easy, but checking it and
adding conditional code for it to work on both Python 2 and 3 can not
be blindly done without having binaries for Phoenix that run on both
Python versions. How do you test your changes? 2to3 is good in telling
you what you need to change to make your code work on Python 3 (and
maybe 2.7), but it doesn't give you back the conditionals to make it
work from 2.5 to 3.2. *That* would be a real 2to3
One time I tried this the resulting app went from being around 100mb to
around 30mb with stripping and thinning.
What I'd like to see is a "Hello, World" application, before and after, in
terms of MB, on Mac.
+Inf
I was considering buying a Mac for my wife (and surreptitiously
stealing it from time to time) to finally be able to test few things
on this funny platform - I mean, if I am ever able to make wxPython
run on it.
Other than that, once upon a time I wished wxPython were the official
GUI framework for Python. Now I am convinced that it is so much better
the way it is now. Python release schedule is awfully out of sync with
the wx one, not to mention that a tremendous effort from the
developers was/is needed for the port to Python 3 (which is not ready
yet), just because now "print is a function".
Great.
At least for the common cases, print("Hello World!") works in Python 2.x too. (You're just printing a tuple with a string in it there.) So many of the print changes needed could run under 2 and 3 without problems. I think module imports would probably be one of the biggest issues to deal with.
I know, it was just an exaggeration; my point was, the Python 3 port
is a whole lot of work for C extensions with a very small gain. I
would rant much less if bolder moves were made during the inception of
Python 3 (but not like Perl 6).
Yeah, that is very true. When you break compat, you should always put in some tempting goodies with it to entice people.
At least part of the wxPython delays with py3 are actually caused by doing Phoenix at the same time, so that we get leaner bindings, faster loading, etc. all at the same time. We could have done a SWIG hack for Py 3, it would just have delayed Phoenix. And really, the big conversion work that needs done is wx.lib, which could be worked on at any time by some adventurous hackers willing to do some 2to3 conversions, work out any conditional code needed for 2 and 3 support to co-exist, and posting patches. I really wish I had more time to hack on wxPy stuff, Py 3 is about the first thing (after a Win build bot) that I'd start hacking on.
As far as I remember (but I may be wrong), Amaury was maintaining a
set of 2to3 patched things for wxPython, including wx.lib (but my
memory may fail me here…).
Maybe he could give us an update. Definitely if the wx.lib 2to3 stuff is working for 2.5 and up, it would be great to start getting those landed. The stuff I looked at mainly was the SWIG stuff, and by that time we were already seeing what kind of boost we could get from SIP.
The 2to3 conversion per se is relatively easy, but checking it and
adding conditional code for it to work on both Python 2 and 3 can not
be blindly done without having binaries for Phoenix that run on both
Python versions. How do you test your changes? 2to3 is good in telling
you what you need to change to make your code work on Python 3 (and
maybe 2.7), but it doesn't give you back the conditionals to make it
work from 2.5 to 3.2. *That* would be a real 2to3
Yeah, hence my comment of this being the next step after the build bot, because the build bot can test a lot of stuff for us, definitely at least that modules import properly for 2.x and 3.x.
Regards,
Kevin
···
On Apr 10, 2012, at 1:43 PM, Andrea Gavana wrote:
On 10 April 2012 22:30, Kevin Ollivier wrote:
On Apr 10, 2012, at 1:12 PM, Andrea Gavana wrote:
On 10 April 2012 22:04, Kevin Ollivier wrote:
On Apr 10, 2012, at 12:23 PM, Andrea Gavana wrote:
As far as I remember (but I may be wrong), Amaury was maintaining a
set of 2to3 patched things for wxPython, including wx.lib (but my
memory may fail me here�).
Maybe he could give us an update. Definitely if the wx.lib 2to3 stuff is working for 2.5 and up, it would be great to start getting those landed. The stuff I looked at mainly was the SWIG stuff, and by that time we were already seeing what kind of boost we could get from SIP.