From: Roger B. <ro...@ro...> - 2003-12-10 03:03:58
|
> The sha module is being imported by one of the com_*.py modules. Since > they are dynamically loaded at runtime, the bundle procedure cannot > find the dependancy. It is only looking at import statements for the > main script and anything imported below that via import statements. Ok. I could also add a redundant import sha in another module. > -rw-r--r-- 1 n9yty admin 1093458 9 Dec 07:53 Modules.zip > -rw-r--r-- 1 n9yty admin 521 15 Nov 06:16 bp.py > -rw-r--r-- 1 n9yty admin 15059 8 Dec 09:07 com_brew.py > -rw-r--r-- 1 n9yty admin 4390 15 Nov 06:16 com_lg.py > -rw-r--r-- 1 n9yty admin 4791 6 Dec 20:52 com_lgtm520.py > -rw-r--r-- 1 n9yty admin 30153 7 Dec 00:12 com_lgvx4400.py I assume that Modules.zip just contains the .py files. I also assume this directory structure isn't writable when deployed. On Linux and Windows the .py files are compiled to .pyo files (optimised). This means that all the doc strings are stripped out which makes them considerably smaller. > 14M dist What size does the final distributable work out as. IIRC you make a dimg (disk image) which is a compressed loopback filesystem. > So here, again, are the needed statements to make it work (output goes > in 'dist') BTW I assume that sys.platform returns 'darwin'. Also how do you encode the version numbers of BitPim itself. On Windows the installer has a unique id associated with BitPim and uninstalls an existing version first before putting a new one on. The version number is in the installer, and part of the setup.exe filename. The default install location is c:\Program Files\bitpim On Linux, the files end up in /usr/lib/bitpim-version. There is wrapper script as /usr/bin/bitpim that execs the main binary out of /usr/lib/bitpim-version. In both cases you could have multiple versions installed, and they would work, but noone does that in practise (and you would have to put a little effort in to convince the installers you really want to do that). I have integrated the code into makedist.py. Thanks for your continuing contributions on this. Roger |