Re: Status report on python2 transition
Bruce Sass [EMAIL PROTECTED] writes: Surely adopting a convention of... #!/usr/bin/env python[major.minor] ...is preferable. It does the same thing without additional runtime overhead and without creating a class of Debian-specific Python programs. I object to this. It make scripts not portable to other systems as it currently does with current python 2.0 scripts in Debian. We shall end up with this trick as soon as possible. -- Jérôme Marant
Re: Status report on python2 transition
More random thoughts... How many versions of Python do we really need to support at one time? Zope and Mailman both need Python 1.5.2 (and depend on python-base = 1.5.2-x, BTW), but don't need any extra packages like mxDateTime. If there are any other packages that don't work with Python 2.1, do they need extra extensions themselves? It seems to me that each stable release of Debian will only need to support a maximum of two different versions of (C)Python, both of which will be quite different. All extra Python modules just have to be compiled against the latest package, and the version of Python from the last Debian release can be removed. For example, woody will have Python 1.5.2 and 2.1.1 when it's released. By the following release of Debian, 2.2 or even 2.3 will be current. Will there be any packages that need 2.1.1 by then? I think I was trying to make a point here: Especially while the freeze is beginning for woody, there's no time to design, implement, test and deploy any scheme for sharing module source, etc., or for doing really fancy dependencies. Instead we should ensure that there is a smooth upgrade path from potato to woody, and that future improvements for woody+0.1 are not ruled out. So... Python 1.5.2, in package python-1.5, installs modules in /usr/lib/python1.5/, installs the binary in /usr/bin/python1.5 and uses alternatives for /usr/bin/python. It conflicts with python-base. Zope and Mailman are recompiled with dependencies on python-1.5 (no versioned depends). Python 2.1.1, in package python-2.1, installs modules in /usr/lib/python2.1/, installs the binary in /usr/bin/python2.1, and uses alternatives, with a higher priority than python-1.5. python-2.1 conflicts with python-base, too. All other packages providing Python modules or using libpython, are recompiled against 2.1.1, with an unversioned dependency on python-2.1. python-base is removed from the archive. Virtual package python turns into a real but empty package, that depends on python-2.1. Scripts written in Python may depend on python, but may expect bug reports later when they turn out to be incompatible with a new version of Python. (Or an old version via alternatives. They should probably just depend on python-2.1 themselves.) Debian packages that have scripts written in Python should use one of /usr/bin/pythonx.y or /usr/bin/env pythonx.y if they depend on python-x.y. They should use /usr/bin/python or /usr/bin/env python if they depend on python. I have no idea whether /usr/bin/env python or /usr/bin/python is better. /usr/bin/env means that another version of Python can be installed in /usr/local, and scripts using env will start using it. Whether this is good or bad for a Debian package is another question. ... Wow. That got a bit longer than I anticipated. If anyone got down to here, do you have any comments? I can expand on my reasoning if it would help. Thanks. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
Re: Status report on python2 transition
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? The following scema will address such matters: #!/usr/bin/env python[[major[.minor][-][major[.minor]]] The interpretation is like, the major.minor before the - gives the lowest Python release for which the script works. If no lower bound is specified, any release will do. Similar for the major.minor with respect to the upper bound. It is an error to specify a lower and a upper bound without the -, and if there's no - it's ment to only run with this specific version. For this to work one has to make a series of symlinks for all of the above specified pythonlower-upper actually in use at a specific site, either in /usr/bin or in ~/bin, such that pythonlower-upper links to the highest available python release allowed by the upper limmit. Further more we need symlinks linking pythonmajor to the highest available minor release for that major release. 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. -- groetjes, carel
Re: Status report on python2 transition
On 12 Jul 2001, Jérôme Marant wrote: Bruce Sass [EMAIL PROTECTED] writes: Surely adopting a convention of... #!/usr/bin/env python[major.minor] ...is preferable. It does the same thing without additional runtime overhead and without creating a class of Debian-specific Python programs. I object to this. It make scripts not portable to other systems as it currently does with current python 2.0 scripts in Debian. We shall end up with this trick as soon as possible. How not portable? Any build of Python I have done installs both: bin/pythonmajor.minor and bin/python as hardlinks... ...calling python-wrapper to execute the program is definately not portable to other systems. - Bruce
Re: Status report on python2 transition
On Jul 12, Bruce Sass wrote: On 12 Jul 2001, Jérôme Marant wrote: Bruce Sass [EMAIL PROTECTED] writes: Surely adopting a convention of... #!/usr/bin/env python[major.minor] ...is preferable. It does the same thing without additional runtime overhead and without creating a class of Debian-specific Python programs. I object to this. It make scripts not portable to other systems as it currently does with current python 2.0 scripts in Debian. We shall end up with this trick as soon as possible. How not portable? Any build of Python I have done installs both: bin/pythonmajor.minor and bin/python as hardlinks... ...calling python-wrapper to execute the program is definately not portable to other systems. True... but it would only be done by Python scripts in Debian packages that depend on external modules. The problem with a hardcoded version in the #! path is that it locks the script into running with that version. Let me give you a for instance: - I create a package that uses and depends on python-newt. Python-newt is only supplied for Python 1.5 at the moment, so I hardcode a call to /usr/bin/python1.5 - python-newt's maintainer releases a new python-newt that works with python 2.1, and drops python 1.5 support. - I install the new python-newt (and probably a lot of the python-2.1-*) - My package is now broken and I have to reupload it, even though all I need to change is the #!. With python-wrapper: - python-newt's maintainer does the right black magic with the python-wrapper business. - I create a package that uses and depends on python-newt. I call /usr/bin/python-wrapper. - python-newt's maintainer releases a new python-newt that works with python 2.1, and drops python 1.5 support. - I install the new python-newt (and probably a lot of the python-2.1-*) - My package still works fine, since python-wrapper knows that this version of python-newt needs python 2.1 to run. Now, two questions arise from all this: - Are we willing to have One and Only One Python in each stable release? If so, screw this python-wrapper business. It really doesn't solve any problems with locally-installed Pythons, except by making sure Debian packaged python programs don't use local pythons. But we will need to figure out some way to cleanly deal with not having python 1.5 in woody (a long Conflicts line looks likely). - If we aren't willing to do this, then we either live with a lot of messy dependencies that have to be updated every time a new x.y python comes out, or go with something like python-wrapper that leaves dealing with new Pythons mostly painless. The only other solution is to call python-wrapper /usr/bin/python, and make it fallback to calling a Python interpreter (defined by alternatives or whatever) if no suitable wrapper is found. That is completely portable, except in the case where /usr/bin/python is expected to be an ELF binary (does freeze need this?), but it adds overhead to every invocation. I have nothing invested one way or the other, mind you. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Doctoral Student, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5949
Re: Status report on python2 transition
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-x2 root root 3040 Apr 10 02:09 /usr/bin/python
-rwxr-xr-x2 root root 3040 Apr 10 02:09 /usr/bin/python1.5
-rwxr-xr-x1 root root 3080 Jun 23 15:52 /usr/bin/python2
lrwxrwxrwx1 root root7 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 pythonmajor.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
Re: Status report on python2 transition
On Thu, 12 Jul 2001, Chris Lawrence wrote: On Jul 12, Bruce Sass wrote: bin/pythonmajor.minor and bin/python as hardlinks... ...calling python-wrapper to execute the program is definately not portable to other systems. True... but it would only be done by Python scripts in Debian packages that depend on external modules. Ok The problem with a hardcoded version in the #! path is that it locks the script into running with that version. Let me give you a for instance: ... - My package is now broken and I have to reupload it, even though all I need to change is the #!. ya, bummer. With python-wrapper: - python-newt's maintainer does the right black magic with the python-wrapper business. ... - My package still works fine, since python-wrapper knows that this version of python-newt needs python 2.1 to run. ya, nice. Of course, it is up to you with @debian.org addresses to ultimately decide if the black magic route is best. Now, two questions arise from all this: - Are we willing to have One and Only One Python in each stable release? How about, bin/python must meet certain minimum requirements. Is there any difference between having only one Python installed, and only using one of the Pythons that are installed? ...and is it OK if that effect is achieved by convention, as opposed to explicit dependencies? I must admit, I am thinking of stable... is it likely that the (for instance) version of python-newt is gonna change on you after a release... or is the example confined to unstable? If so, screw this python-wrapper business. It really doesn't solve any problems with locally-installed Pythons, except by making sure Debian packaged python programs don't use local pythons. But we will need to figure out some way to cleanly deal with not having python 1.5 in woody (a long Conflicts line looks likely). Hmmm, have 1.5.2, 2.0.1, and 2.1.1 in Woody, adopt the convention bin/python be at least equivalent to python2.0, have any packages still depending on 1.5.2 explicitly state so and use python1.5 in their executables (everyone else can assume #!/usr/bin/env python gets you 2.0 or better. - If we aren't willing to do this, then we either live with a lot of messy dependencies that have to be updated every time a new x.y python comes out, or go with something like python-wrapper that leaves dealing with new Pythons mostly painless. I'm not really sure how messy the dependencies would get (I tend to only pay attention when something is messed up and I need to edit .../dpkg/status as a work around), but I would only expect it to be so (maybe) for those depending on an old version of Python... good incentive to get it working with a more current Python. ;) The only other solution is to call python-wrapper /usr/bin/python, and make it fallback to calling a Python interpreter (defined by alternatives or whatever) if no suitable wrapper is found. That is completely portable, except in the case where /usr/bin/python is expected to be an ELF binary (does freeze need this?), but it adds overhead to every invocation. The python replacement (a.k.a python-wrapper) could be an ELF executable, it may still require a Debianized freeze module, but the overhead would be less. - Bruce
Re: Status report on python2 transition
Bruce Sass [EMAIL PROTECTED] writes: bms:~# ls -l /usr/bin/python* -rwxr-xr-x2 root root 3040 Apr 10 02:09 /usr/bin/python -rwxr-xr-x2 root root 3040 Apr 10 02:09 /usr/bin/python1.5 -rwxr-xr-x1 root root 3080 Jun 23 15:52 /usr/bin/python2 lrwxrwxrwx1 root root7 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. $ ldd /usr/bin/python1.5 libpython1.5.so.0.0 = /usr/lib/libpython1.5.so.0.0 (0x4001f000) ... $ ldd /usr/bin/python2.0 libpython2.0.so.0.0 = /usr/lib/libpython2.0.so.0.0 (0x4001f000) ... These *are* real executables; it looks like all they do is call Py_Main from whichever libpython they're linked against. [...] 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. Agreed, although it seems OK to me to only expect them to work with the current version, in any stable release of Debian. As the language changes, adding keywords like yield and div, etc., expecting full forwards compatibility might be a little unreasonable. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
Re: Status report on python2 transition
Chris Lawrence [EMAIL PROTECTED] writes: - My package is now broken and I have to reupload it, even though all I need to change is the #!. They'll probably be Debian policy changes, new upstream versions of your program, and/or changes in the Python language that require you to do a new upload between releases anyway. IMO, the minimal effort required here isn't worth the black magic. -- Carey Evans http://home.clear.net.nz/pages/c.evans/ Quiet, you'll miss the humorous conclusion.
