On Tue, Jul 03, 2001 at 02:53:11PM +0200, Gregor Hoffleit wrote:

Right, I forgot about that. It's not so bad for Debian though, since most of our packages byte-compile the stuff only when unpacking the package. Since installation of a new python-base package recompiles the complete site-packages tree (but not yet site-python, you got me ;-), we're not hurt by that problem.

What about when you want to have multiple python versions, like python 1.5.2, 2.0.1, 2.1.1 and 2.2-CVS-snapshot ? :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

On Tue, Jul 03, 2001 at 03:05:35PM +0200, Gregor Hoffleit wrote:

Seriously, does anybody (besides the Python developers) feel a need to have multiple Python versions on the same system ?

Well, currently anyone who wants to use python2.0+ does, yes. It's up to you, not me, whether that should be continued :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

On 03 July 2001, Gregor Hoffleit said:

So let me paraphrase: Provided the maintainer of the Debian Python package would do a good job and keep the package always up-to-date, would you think there's a real world need for concurrent Python versions on the same system ?

Speaking as someone who uses Python day-to-day and occasionally worries about compatibility across Python versions: yes, it would be really nice if Python better supported multiple versions installed at the same time. lib/python1.5, lib/python2.0, and lib/python2.1 just don't cut it: I remember running 1.5.1, 1.5.2, and alpha/beta versions of 1.6 simultaneously. I had to install each to a separate prefix, which was ugly but workable. It would be nice if Python (and, yes, the Distutils now) had better native support for multiple simultaneous versions. Speaking as the main perpetrator of the Distutils: AAUUGGHGHHHH!!!! NOOOOO!!! Please, don't make me look at this stuff AGAIN!!!! Aiiieeee!! But seriously: I think I once attempted to convince Guido that a revamped organization of the library directories would be a good idea, and that the Distutils would be a good way to introduce that scheme. Obviously, I didn't convince him, so we still have the same system. The one glimmer of good news is that the Distutils "install" command is insanely flexible; if you can manage to wrap your head around the 17,000 levels of indirection, it should be a simple matter of changing a few hard-coded dictionaries (there are two for Unix, and one each for Windows and Mac OS) to introduce a completely new installation scheme. I probably had some expectation that someday this discussion would open up again. BTW, I'm skeptical about keeping .py and .pyc code in a non-Python-version-specific directory (ie. site-python). Debian's bytecode-recompilation at installation time scheme sounds cool, but the desire/need to have multiple Python versions available kind of nixes it. Bummer. Oh yeah, another thing I vaguely recall from the pre-Distutils-0.1 era: Guido doesn't (didn't?) like site-python and wanted to deprecate it. Perhaps the above paragraph explains why. Greg -- Greg Ward - Linux geek gward@python.net http://starship.python.net/~gward/ Drive defensively -- buy a tank.

Speaking as someone who uses Python day-to-day and occasionally worries about compatibility across Python versions: yes, it would be really nice if Python better supported multiple versions installed at the same time. lib/python1.5, lib/python2.0, and lib/python2.1 just don't cut it: I remember running 1.5.1, 1.5.2, and alpha/beta versions of 1.6 simultaneously. I had to install each to a separate prefix, which was ugly but workable. It would be nice if Python (and, yes, the Distutils now) had better native support for multiple simultaneous versions.

That was mostly because we were abusing the version numbering scheme to roll out feature releases with a micro version number (1.5.1, 1.5.2). We don't do that any more -- feature releases have a minor (middle) version number change. If you really need to distinguish Python 2.0 and 2.0.1 on the same system, you're a Python developer by definition. :-)

Speaking as the main perpetrator of the Distutils: AAUUGGHGHHHH!!!! NOOOOO!!! Please, don't make me look at this stuff AGAIN!!!! Aiiieeee!!

BTW, Greg, there's this bug I've found in Distutils, but the margin of this email isn't wide enough to describe it. :-)

But seriously: I think I once attempted to convince Guido that a revamped organization of the library directories would be a good idea, and that the Distutils would be a good way to introduce that scheme. Obviously, I didn't convince him, so we still have the same system.

Which I think isn't so bad given that we now have a well-behaved versioning policy in place.

The one glimmer of good news is that the Distutils "install" command is insanely flexible; if you can manage to wrap your head around the 17,000 levels of indirection, it should be a simple matter of changing a few hard-coded dictionaries (there are two for Unix, and one each for Windows and Mac OS) to introduce a completely new installation scheme. I probably had some expectation that someday this discussion would open up again.

BTW, I'm skeptical about keeping .py and .pyc code in a non-Python-version-specific directory (ie. site-python). Debian's bytecode-recompilation at installation time scheme sounds cool, but the desire/need to have multiple Python versions available kind of nixes it. Bummer.

Yes, good point. Bytecode is generally not compatible between versions -- its specification is considered an internal detail of the implementation (again, it can't vary with a micro-version, but it can and usually does vary with the minor version number).

Oh yeah, another thing I vaguely recall from the pre-Distutils-0.1 era: Guido doesn't (didn't?) like site-python and wanted to deprecate it. Perhaps the above paragraph explains why.

Indeed, /usr/local/lib/python<major>.<minor>/site-packages/ is where site packages should go. --Guido van Rossum (home page: http://www.python.org/~guido/)

...

...

...

...

"GH" == Gregor Hoffleit writes:

GH> You've hit the forbidden question ;-) GH> Seriously, does anybody (besides the Python developers) feel a GH> need to have multiple Python versions on the same system ? Yes, definitely as both a Zope and Mailman developer <wink> I need multiple Python versions. But I suspect even normal users of the system will need multiple versions. Different Python-based apps are requiring their users to upgrade Python on their own schedule, so multiple versions will still be required. -Barry

...

What about when you want to have multiple python versions, like python 1.5.2, 2.0.1, 2.1.1 and 2.2-CVS-snapshot ? :-)

You've hit the forbidden question ;-)

Seriously, does anybody (besides the Python developers) feel a need to have multiple Python versions on the same system ?

I've had enough requests over the years for this, so it is indeed supported, and I believe there is a need. Quite often people have important programs that for some minor reason don't work on a newer version yet and they can't find the person or the time to fix it. Python's standard installation makes this possible. You can have only one "python" but you can request a specific version by appending the "major dot minor" part of the version number, e.g. python1.5, python2.0, python2.1, python2.2. "python" is a hard link to one of these. You can't (easily) have multiple version with the same major.minor, but that should never be needed. I've heard though that some Linux distributors break this versioning scheme in favor of their own.

If there's a real world need for this, then, yes, we had to come up with a completely different setup. I guess this setup might involve symlink farms (urghh).

Ugh maybe, but it's the only thing that scales. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Tue, Jul 03, 2001 at 02:53:34PM +0200, Thomas Wouters wrote:

On Tue, Jul 03, 2001 at 07:38:00AM -0500, Jeff Epler wrote:

...

On Tue, Jul 03, 2001 at 02:09:51PM +0200, Gregor Hoffleit wrote:

...

Due to Python's good tradition of compatibility, this is the vast majority of packages; only packages with binary modules necessarily need to be recompiled anyway for each major new <version>.

...

Aren't there bytecode changes in 1.6, 2.0, and 2.1, compared to 1.5.2? If so, this either means that each version of Python does need a separate copy (for the .pyc/.pyo file), or if all versions are compatible with 1.5.2 bytecodes (and I don't know that they are) then all packages would need to be bytecompiled with 1.5.2.

None are compatible. This might change, but I don't think so -- I think the CVS tree already has a different bytecode magic than 2.1, though I haven't checked. Perhaps what Gregor wants is a set of symlinks in each python version's site-packages directory, to a system-wide one, and a 'register-python-version' script like the emacs/xemacs stuff has that adds those symlinks. That way, the .pyc/.pyo versions would remain in the version-specific directory.

Sounds like a LOT of symlinks. To be honest, I would prefer to postulate that there's only one official Python version on a Debian system at a time. Then, the postinst and prerm scripts of python-base could take care of removing and recompiling .pyc and .pyo files at install time of a new Python version. Certainly, this won't work for packages that ship with precompiled .pyc/.pyo files, and we have to provide a method for registering .py files in non-standard places. If all of this was in place, I don't see a reason *not* to use site-python instead of site-packages... Gregor