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

[Steven P. <n9...@n9...>]

On Mar 15, 2004, at 10:41 AM, Tom Pollard wrote:
>>> 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.

  Well, look at it this way... If you intentionally choose to not 
install that piece, then you choose to break things that might depend 
on it. So yes, you have that choice, but there are consequences for it. 
I don't know what else you would also potentially break, but it's easy 
enough to simply put in the requirements of your software program that 
you require the BSD subsystem be installed. I'd liken the 'optional' 
but here to also say that printer drivers are optional, and you don't 
have to install them... Now, is it up to the application developer to 
figure out that you didn't and somehow work around that? Maybe a far 
stretch, but similar in the vein that the user took some intentional 
action to remove a part of the standard install.

  Now, if this were a company product where real money was being charged 
for it and there were a compelling reason to make it as idiot proof as 
possible, despite what the users may have done to their system, then 
I'd agree with you and would be compelled to try to make it work. 
However, that is not the case, and there are design decisions to use 
the base or common denominator of a standard set of components on top 
of a standard install of the operating system with it's default 
options. Just my opinion, anyway.

  I'm not intimately familiar with Python, this is the first time I've 
worked with it. However, after discussing things on the PythonMac 
mailing list, it came out that bundlebuilder.py was the way to generate 
a bundle. It doesn't mean it's the best, or the most fool-proof, etc... 
So the options are possibly open for an alternative, nobody can be 
aware of every alternative way to do something, no more than they can 
know every conceivable end-user configuration they'll be running 
against. If they could, I suppose we'd have no bugs or errors in 
shipping code. :-)

> Anyway, thanks for being willing to discuss it.

  Always open here, I don't claim to have any lock on the best way to do 
things (if there is one, opinions abound...) and can always learn 
something new and useful.