Re: [Bitpim-devel] Startup script for BitPim on Macs

[Tom P. <mlp...@ea...>]

On Mar 15, 2004, at 10:59 AM, Steven Palm wrote:
>> I'm not sure how things are done on the other platforms, but I would 
>> have expected you to use the 'freeze' system for packaging a  script 
>> as a standalone executable, similarly to 'perl2exe' and it's ilk.
>
>  Except, as far as I know, that does not work properly on MacOS X. 
> Prove me wrong, I won't mind. ;^

I have no idea what the state of 'freeze' on Macs is, to be honest - 
I'm a python newbie.  (I do use ActiveState's 'PerlApp' under Windows 
and the open-source 'PAR' package under Unix (including MacOS X) for 
packaging Perl scripts as executables.)


>> the user to have a separate, working Python installation.  From the 
>> recent problem report on the bitpim-user list, we saw that Python is 
>> an optional install on MacOS X.  The BitPim startup script doesn't do 
>> anything that you can't do just as easily with a shell script, and a 
>> shell script would remove the need for a working Python on the user's 
>> machine.
>
>  An optional install, yes, but one that is marked by default on every 
> installation. So, unless a user intentionally goes out of their way 
> when doing the install or upgrade to make it NOT install, it will be 
> there.

If it's optional, it's optional.  Running ordinary apps under MacOS X 
doesn't require its presence.  My understanding is that it's mainly 
there to support Terminal users and Unix geeks.  If it was my company's 
product, I'd insist on taking this simple step to make sure my app ran 
on a minimal install of the OS.


> Also, it was not my design to build the bundle this way, I am using 
> the standard "bundlebuilder.py" routine that is part of the Python 
> distribtution and is, as far as I can tell, the accepted and 
> "approved" way to build distributable bundles on MacOS X. To wedge in 
> a different script would require gutting the work done by 
> bundlebuilder.py and making it a manual process each time.

I didn't realize that.  I'd also be disinclined to muck with 
bundlebuilder.py unless there was some stronger reason than this.  
Maybe if the issue comes up again I'll lobby the bundlebuilder 
maintainer to accept this change.  Just on technical grounds, it seems 
clearly the right way to go.  Anyway, thanks for being willing to 
discuss it.


Cheers,

Tom