On Sun, 31 Jan 2010 09:50:16 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <mar...@v.loewis.de> wrote: > >> 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).
Excellent, thank you. IMO this explanation should go in the PEP. By the way, the part that caused me the most confusion in the language in the PEP was the emphasized *and their dependencies*, as if a package having dependencies somehow turned the problem into a factorial explosion. But there seems to be nothing special, according to your explanation, about dependencies in this scheme. > > (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? Arg. My fingers added the 'c' without my mind getting involved, apparently. I meant that the .py is installed directly in each site-packages. > How does it deal with a Python installation that happens after the > package installation? There's a tool that runs through all installed python packages and does the install and byte compile (basically, reinstalls the package for the new Python version). Gentoo doesn't have the multiple-os-packages-per-Python-version problem, since it installs from source. It seems like it would be simple enough to enhance the os packaging systems to allow the install path to be specified at install time, if that really is the only difference between the package versions. And a script that runs through all the installed python packages and installs them for a new Python version when a new version is installed should be as easy for other distributions as it is for Gentoo. That would also mean that dependencies on the Python version would be handled by the packaging system: it would refuse to install a given package if that package didn't support the specified Python version. Or is something missing from my understanding? If not, I think the motivation section should address why the PEP is a better idea than improving the os packaging systems as I've suggested. (The os vendors are going to have to change details of their packaging systems if the PEP is accepted, so it's not as if the PEP saves the vendors work.) -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls _______________________________________________ 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
