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 [EMAIL PROTECTED] _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
