>> Linux distributions such as Ubuntu [2]_ and Debian [3]_ provide more >> than one Python version at the same time to their users. For example, >> Ubuntu 9.10 Karmic Koala can install Python 2.5, 2.6, and 3.1, with >> Python 2.6 being the default. >> >> In order to ease the burden on operating system packagers for these >> distributions, the distribution packages do not contain Python version >> numbers [4]_; they are shared across all Python versions installed on >> the system. Putting Python version numbers in the packages would be a >> maintenance nightmare, since all the packages - *and their >> dependencies* - would have to be updated every time a new Python >> release was added or removed from the distribution. Because of the >> sheer number of packages available, this amount of work is infeasible. > > As a non-Debian user (I'm a Gentoo user), the above doesn't enlighten me, > even after skimming the referenced document. Perhaps an example would > be helpful?
I think the basic question is: how do you get stuff into /usr/lib/python2.6/site-packages/Pyrex? One option would be to have a Debian package python26-pyrex. Then you would also need a python25-pyrex package and a python27-pyrex package, all essentially containing the very same files (but installed into different directories). What they want is a single python-pyrex package that automatically works for all Python versions - even those that aren't yet installed (i.e. install python-pyrex first, and Python 2.7 later, and python-pyrex should be available). Having a single directory in sys.path for all Python versions currently doesn't work, as the pyc files for each version would conflict. The current solution consists (for package installation) of a) installing the files in a single place b) creating a directory hiearchy in each Python's site-package c) symlinking all .py files into this directory hierarchy d) byte-compiling all .py files in the hierarchy For installation of new Python versions, they need to a) walk over the list of installed Python packages b) for each one, repeat steps b..d from above With the PEP in place, for pure-Python packages, they could a) have a system wide directory for pure-Python packages, and b) arrange that directory to appear on sys.path for all Python versions On package installation, they then could a) install the files in that system-wide directory b) for each Python version, run byte-code compilation of the new package On Python installation, they would a) byte-compile the entire directory. Alternatively, to support packages that don't work with all Python versions, they could continue to use symlinking, but restrict that onto the top directories of each package (i.e. not create a directory hierarchy in site-packages). > (FYI, Gentoo just installs the pyc files into each of the installed > Python's site-packages that is supported by the package in question...disk > space is relatively cheap.) I suppose Gentoo also installs .py files into each site-packages? How does it deal with a Python installation that happens after the package installation? >> * Would a moratorium on byte code changes, similar to the language >> moratorium described in PEP 3003 [16]_ be a better approach to >> pursue, and would that solve the problem for vendors? At the time >> of this writing, PEP 3003 is silent on the issue. > > Unless the bytecode change moratorium was permanent (unlikely), how would > this solve the vendor issues? A vendor strategy might be to not store .pyc files on disk for some Python versions (i.e. those that differ from the rest). Assume that 3.2, 3.3, 3.4 use the same pyc magic, and 3.5, 3.6, 3.7 also do. Then, at any point in time, one of the Python versions is the "system python" in Debian. This is the one who decides the official .pyc magic. The other Python installations on the same system can either reuse the existing .pyc files (if the magic matches), or not, in which case they have to recompile (to memory) the Python source on every startup. The longer the moratorium, the less of a problem this could cause for users. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
