On Thu, 12 Jul 2001, Carel Fellinger wrote: > On Thu, Jul 12, 2001 at 09:03:07AM +0200, Jérôme Marant wrote: > > Bruce Sass <[EMAIL PROTECTED]> writes: > > > > > Surely adopting a convention of... > > > > > > #!/usr/bin/env python[major.minor] > > > > ... > > I object to this. It make scripts not portable to other systems as > > it currently does with current python 2.0 scripts in Debian. > > True as this might be, the above scema still doesn't address all needs. > The simple case were your script only runs with e.g. 2.1, is covered, > but what happens when a newer Python is released? Is your script then > still running with 2.1? Or do we need to update all scripts in order > for them to use newer Pyton releases?
Right, it is not ideal, but it is portable. > The following scema will address such matters: > > #!/usr/bin/env python[[major[.minor][-][major[.minor]]] ...but is not necessarily portable because Python installs executables under bin/python{,<major>.<minor>}. I'm a little confused... A solution to the problem has already been proposed in previous discussions on this list -- and I though it had already (at least) started to be implemented... bms:~# ls -l /usr/bin/python* -rwxr-xr-x 2 root root 3040 Apr 10 02:09 /usr/bin/python -rwxr-xr-x 2 root root 3040 Apr 10 02:09 /usr/bin/python1.5 -rwxr-xr-x 1 root root 3080 Jun 23 15:52 /usr/bin/python2 lrwxrwxrwx 1 root root 7 Jun 24 18:34 /usr/bin/python2.0 -> python2 ...'cause I've never seen a 3k python executable. So, using an explicit "python-wrapper" in the #! line is a step backwards to me. Unless Python grows the smarts to figure out on its own that there is more than one version of itself available, and which version should be used (not as straightforward as just looking at the code)... the only reasonable solution is to replace bin/python with something that has those smarts, the next best is to be explicit about which Python the program is targeted for. <...> > The above seems complicated, but versioning a language is complicated. > But take heart, Python manages to be fairly downwards compatible, so > the upper bound might not be needed that often, though it is there > for power users trying out stuff tied into specific releases. Yes. I think it is perfectly reasonable for Debian to insist that a specific version of Python be installed, and that any Python programs distributed by Debian must work with a certain version of Python or better. You can then use an unversioned python executable and not worry about breakage when the specific minimum version of Python required by Debian gets bumped up, because Python is backwards compatible. The people who are gonna run into trouble then are those that try to point bin/python at python<major>.<minor>, where major + minor is less than the minimum version Debian expects. If Python breaks backwards compatibility... well, you probably have some editing work to do (as will every other Python developer who wants old code to run without problems) no matter how the infrastructure has been set up (either rewriting the code to not use the obsolete paradigm, or simply specifying a version of python it will work with). - Bruce