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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4