[Python-Dev] PEP: per user site-packages directory (original) (raw)
Christian Heimes lists at cheimes.de
Tue Jan 15 09:54:35 CET 2008
- Previous message: [Python-Dev] PEP: per user site-packages directory
- Next message: [Python-Dev] PEP: per user site-packages directory
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jeroen Ruigrok van der Werven wrote:
One thing I miss in this PEP and discussion is the point of view from a webhosting company and webhosting user.
If the webhoster upgrades his hosting software and Python get updated by a revision (say 2.5 to 2.6) this would in the current case mean that the webhosting user using per-user site-packages is out of luck due to the hard-wired (and apparently needed) version identifier. Or is that a wrong assumption on my side?
The problem exists for almost every Python extension. 3rd party packages with C modules have to be compiled for every Python version. Even pure Python packages don't always work on a new version. You can't expect software to run under every version of FOO, not even the next future version of FOO where FOO is Python, Java, C#, Perl, PHP ... you name it.
It's not the intention of the PEP to solve the problem. A web hoster can support multiple versions of Python at once. You can install every minor version of Python from 2.0 to 3.0 (8 versions) without major conflicts. A good web hoster should give an user several months up to a year to migrate from - say - 2.5 to 2.6. Most Linux distributions (except Redhat) have at least 2.4 and 2.5 in their repositories.
Right now Python faces a lot of problems in the webhosting world because it's tedious to set up and maintain for the webhosting user since they often have to compile and install their own Python in their home directory. The per-user site-packages will help in that aspect a lot, I think, but we do need to detail some more use-cases and scenarios (patterns if you like) on how such deployments would work. I think this is extremely important due to the proliferation of Python now more and more as a choice for webapp development.
Can you write up some use cases for us? I'm especially interested in use cases that are not covered by PEP 370. So far only a few problems come into my mind:
Installation extensions for mod_python, requires root permissions or full control over the Apache process anyway
Multiple versions of an extension. The problem is mostly covered by pkg_resources and setup tools.
Installing a newer version of an extension, covered by PEP 370.
Registering more search paths. Drop a pth file into the user site directory or use a usercustumize.py.
easy_install packages to the user site directory. Setuptools are not part of the Python stdlib. I'm confident that Phil is going to add the feature as soon as the feature is implemented for Python 2.6
What's missing?
Christian
- Previous message: [Python-Dev] PEP: per user site-packages directory
- Next message: [Python-Dev] PEP: per user site-packages directory
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]