[Pythonmac-SIG] py-appscript problem in crontab

[Christopher Barker]

Leonardo Santagada wrote:
> And you also make the user know that they are not welcome to install  
> python were he wants...

It all depend in who the "user" is, and who the "author" is.

> Try to at least put #!/usr/bin/env python2.5 if all you want is limit  
> the python to a specific version, 

That's exactly what I usually do, but it doesn't help the OP's case -- 
there is Apple's Python2.5, and there may be MacPython2.5 (and fink25, 
and ...) each of these may have different packages installed, and thus a 
given script will only work with a given one.

 > but even then I think it is a really
> bad idea for any code you want to use in more than one machine as  
> maybe your script will run fine in python 5.3 (made up number I know)  
> and you are limiting it to a freaking old python

No you're not -- you're limiting it to run on only that python without 
the user (installer, anyway), being made aware that they are trying 
running it against a new version, and thus might want to test a bit.

a while back, Redhat had a bunch of admin scripts, all with:

#!/usr/bin/env python

(or maybe just #!python)

at the top. The result was that all kinds of stuff broke when someone 
installed a new version of python that didn't have all of RedHat's 
special modules in it (which hadn't been ported to a newer python) This 
was a big 'ol pain in the *&^*& for lots of people. Had RedHat specified 
a python version, there would have been no problem at all, and one would 
hope that they would want to test all their code against a new version 
when they decided to upgrade, and could change their #! lines then.

I think of scripts depending on Python to be much like a binary 
depending on a shared library -- it's insane to link binaries against 
"libc" without specifying a version, and expect them to work two 
versions of libc later -- why is this any different?

Other options:

messing with global environment variables like PATH and PYTHONPATH -- 
now you're assuming all scripts on your system use the same python -- 
bad idea (see RedHat example)

Having a startup script that specifies PATH and/or PYTHONPATH -- sure, 
that's fine, but is that any different that specifying it in the #! line 
(unless you use one startup script for multiple python scripts, in which 
case, it's a fine solution.

> Sorry for the rant, but I really get upset fixing smallbugs in  
> realesed "Production" code that was hardcoded to run only on the  
> author computer.

I agree -- but which bug would you rather fix -- a #! line that needs 
changing, or some weird bug that's the result of a different python 
version, or even more common, a script that won't run because a package 
is missing (but I have that installed! what's going on!)

The very simplest python script that uses no fancy features of python 
and has no dependencies might well work fine with lots of python 
versions, but even that won't make the py3k transition (long before your 
mythical python5.3), and I'd still like to know what versions it was 
tested on (yes, I can get that from a README, but that's not really any 
easier than reading a #! line, and who knows where the README may be for 
an installed script)

Personally, I'd really like to see versioning somehow built into python 
itself (and python packages -- eggs solve some of this), then you could 
distribute a script that could declare which versions of python a script 
was known to work with, and could automatically run with any of those, 
and raise a useful error with any others.

OOPS! sorry -- that was a much longer rant!

-CHB


-- 
Christopher Barker, Ph.D.
Oceanographer

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

Chris.Barker at noaa.gov