Re: Status report on python2 transition
On Thu, 5 Jul 2001, D-Man wrote:
> On Thu, Jul 05, 2001 at 06:43:08PM +0100, Aquarius wrote:
> | In article <[🔎] 20010705173337.E3258@mediasupervision.de> you wrote:
> | > I just browsed /usr/bin and /usr/sbin, and indeed there are plenty of
> | > scripts that use "#!/usr/bin/env python". If we consider the possibility
> | > that somebody installs non-compatible Python versions in the path, then
> | > these are bugs in that packages. Thanks for pointing this out!
> | >
> | > I guess we really, really need a Debian Python policy that mentions all
> | > these things.
> |
> | Especially since "#!/usr/bin/env python" is recommended in the Python
> | FAQ (section 4.63 --
> | http://www.python.org/cgi-bin/faqw.py?req=show&file=faq04.063.htp). Is
> | it bad to use in general, or just bad to use on Debian systems?
>
> It is bad only when you wanted to use a different version of python
> than the one that is first in the PATH (which is what /usr/bin/env
> will tell you when you ask for 'python').
The problem with both the FAQ and Debian's Python is that they have
been assuming nobody will ever have more than one Python on the
system, and it will always be as recent as the most recent program...
as long as the language is backwards compatible there should be no
problem -- too bad that is not always the case.
The correct way to do it is:
#!/usr/bin/env python[major.minor]
using this heuristic:
If the program will run with any version of Python currently
in use then have "python" execute it, otherwise use the
lowest numbered version you know it will run on, or the
version of Python you are using if you do not know when the
feature was introduced.
The nice thing about the Python documentation is that it usually tells
you when a feature is new to that version... which makes it not too
difficult to decide between using a plain "python" and a versioned one
in the hatch(she)-bang line, without needing to know the history of
Python.
Is PyChecker smart enough to determine the lowest numbered version of
Python a program will run with... that is the kind of functionality
our beloved Python maintainers need to make this necessary transition
a little less painful (or just let the bug reports flow in, after
all, it is gonna be in unstable ;).
> The whole discussion here is how to simultaneously deal with
> different, potentially incompatible or known to be incompatible,
> versions. I don't have any real solutions. Maybe as a reference it
> would be a good idea to mention what I have done for Java on my cygwin
> (win2k) box at work :
<...>
> Maybe that will help someone devise a plan (policy) for Python on
> Debian. If you want those shell scripts, I am more than happy to
> provide them. They are really simplistic hacks, though.
Different versions of Python can co-exist quite well (if you don't
mind a duplication of .py's), so there should be no need to run a
switcher script or wrapper.
I do it this way...
- build py-whatever in /usr/local
- goto the Tools/scripts dir and modify the fixps.py program to change
all hatch-bang lines to use a versioned python executable.
- get rid of the python[major.minor] <--> python hardlink in
/usr/local/bin (it is first in my PATH)
- use the convention I outlined at the start of this message
You can now choose your default Python with a symlink, and every
program you write will work no matter which Python is the default...
and if Debian's Python maintainers adopt this scheme you will not need
to worry about their programs breaking when you change the default
interpreter.
- Bruce
Reply to: