[Pythonmac-SIG] Trying to make an app

[Bob Ippolito]

On Oct 6, 2004, at 4:40 PM, Steven Palm wrote:

> On Oct 6, 2004, at 2:45 PM, Bob Ippolito wrote:
>> I'll see if I can change sys.path[0] without breaking anything useful.
>
>  Thanks. Honestly, I don't know which is more "intuitive" or "better", 
>  you're in a much better position than I am to make a decision about 
> what is generally a "better" idea for most people.
>
>>>  On the other hand, the bundlebuilder process produces a 15MB 
>>> package, while the py2app package is about 40MB, so maybe it's not 
>>> time to switch yet until you are able to strip out unneeded parts of 
>>> referenced modules.
>>
>> Probably because the bundlebuilder process isn't embedding everything 
>> it actually needs,
>
>  Well, it does run fine on virgin systems that have no non-standard 
> components installed. However, if py2app is bundling in a whole python 
> distribution and bundlebuilder is relying on the system install, then 
> it would explain it.

That depends on if you're using the vendor provided Python or not.  In 
this case it is using the vendor provided Python.  It seems that the 
only possible explanation for the missing 25MB is that py2app is not 
stripping debugging symbols from the included extensions and dylibs 
(particularly wx).  I'll add an option to do that, but until then you 
can do something like :
find BitPim.app -name "*.so" -or -name "*.dylib" -exec strip {} \;

and see if that makes a difference.

>>  or you're including too many packages explicitly without reason.
>
>  Not sure, most of the code is Roger's.

I was referring to the setup.py

>>   Either that or there's a WHOLE LOT of python code and you should 
>> turn on zip compression.  I can't know unless I can see a ls -lR of 
>> what went in there or something.  If I don't get this kind of 
>> assistance from users like you then py2app will likely never suit 
>> your needs, so don't throw it away yet .. it's probably a trivial 
>> fix.
>
>  I'm not about to throw it away, you've worked too hard on it. ;-)  I 
> jumped on the testing bandwagon when I saw your announcement precisely 
> because I wanted to provide feedback on how it works for random app 
> out in the wild.
>
>  By the way, I cannot get the "dist_dir" option to use the directory 
> specified, the output bundle always goes in my current directory 
> (where setup.py is).

dist_dir isn't what you think it is.. I'm using the same semantics as 
py2exe (which I don't particularly like, so that may change).  In order 
to change the resultant executable destination you have to do:

setup(
	app = [
		dict(script="myscript.py", dest_base="./dist"),
	],
)

  BitPim.app/Contents/Resources/Python/lib-dynload/native/usb

>  One more issue is that some package parts are loaded dynamically, 
> such as this:
>
> dlg=CommPortDialog(self, 
> __import__(self.phonemodels[self.phonebox.GetValue()]), 
> defaultport=self.commbox.GetValue(), sashposition=p)
>
>  It complains that it cannot find the module referenced by 
> self.phonemodels[self.phonebox.GetValue()]).
>
>  For bundlebuilder, I was doing this:
>
>     coms=glob.glob("com_*.py")
>     for c in coms:
>         myapp.includePackages.append(c[:-3])
>
>  For py2app, I was just using passing a build includePackages list in 
> via the "packages" element in the options dict. I cannot find the 
> comm_* files anywhere in the generated bundle, in the 
> site_packages.zip file or outside of it. They are included as:
>
>     options = dict(p2app=dict(
>                  optimize=2,
>                  dist_dir="./dist/",
>                  compress=1,
>                  packages=includePackages,
>                  includes=data_files,
>                  iconfile=iconfile,
>                  plist=plist))
>
>  where includePackages is built above.

There are several problems with this:
There is a typo in the options dict.. it should be:
dict(py2app=dict(

dist_dir doesn't do what you think it does (as stated above).

packages are python packages (as in, folders with __init__.py).  That 
should be includes instead.

includes is not for data files.  data_files should be passed to the 
setup function directly.

>  Also, the dependencies checker seems to be missing the fact that 
> libusb must be included... I see it coming up with a libusb.so, but 
> that's just the SWWIG generated stub, I think, in bundlebuilder I had 
> to include the dylib itself.

Can you show me the output of:
otool -Lv 
BitPim.app/Contents/Resources/Python/lib-dynload/native/usb/_libusb.so

Where is this usb package and how do I build it so I can see what it's 
doing?

btw - svn trunk includes the encodings package instead of including it 
as a package.. so that gets rid of a bunch of files and should save 1mb 
or so (before compression).

-bob