[Python-Dev] Order that site-packages is added to sys.path (original) (raw)
Barry A. Warsaw barry@zope.com
Tue, 12 Feb 2002 11:43:24 -0500
- Previous message: [Python-Dev] Order that site-packages is added to sys.path
- Next message: [Python-Dev] Order that site-packages is added to sys.path
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
"MvL" == Martin v Loewis <martin@v.loewis.de> writes:
MvL> I think the rationale was that you are precisely not supposed
MvL> to override any of the standard modules. It was considered a
MvL> good thing that if you do "import string" in some version of
MvL> Python, you know exactly what you will get.
Okay, I can see why that's useful.
Let's say there was a way to add stuff to the front of sys.path, such that they could override the standard library. This might work just fine on a single user (or single application) system, but might be very broken on a multiuser or multiapp system ("I know what I'm installing in site-packages, so what's the problem?").
Hopefully, any overrides that were installed would be API compatible with the standard. Such overrides would probably be allowed to fix bugs or add functionality, but not remove functionality. This might still get us into trouble and this path leads to module versioning, etc. I don't want to go there now.
I know how to handle my specific case (I've done it before), but just to close the loop, I can't wait for Python 2.2.1 because some of the features I'm depending on are new features, not just bug fixes. I think those will have to wait for Python 2.3 to be safe, so until then, I must distribute a separate package. That's fine, I can live with that.
I think "python setup.py install --root blah" will do the trick for me, along with some application specific path-hackery.
-Barry
- Previous message: [Python-Dev] Order that site-packages is added to sys.path
- Next message: [Python-Dev] Order that site-packages is added to sys.path
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]