[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status report on python2 transition



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 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 :

    I have jdk 1.1.8, jdk 1.2.2, and jdk 1.3.0 installed into various
    directories.  As is common with windows and java everything for
    that version lies under that base directory (ie d:\jdk1.1.8).  I
    have some shell scripts in my path called 'java1' 'java2' and
    'java3'.  I have a symlink from 'java' to the version I want to be
    the default.   Then I can pick which JVM to run the java code by
    simply switching the command slightly.  The shell scripts set the
    JAVA_HOME environment variable to match the selected JVM.  I also
    added a command line switch, --classpath, that _appends_ the jar
    files to the existing classpath (which would include commonly used
    libraries such as swing or 3rd party libs used by our product).

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.

-D



Reply to: