Jim Fulton wrote:
Gordon McMillan wrote:
Jim Fulton wrote:
[Barry]
A user would drop the kjParsing directory into Shared, and then all the import kjParsing.kjParser statements would Just Work.
To be a standalone application, you can use tricks that Jim Ahlstrom pointed out, or tricks from my Installer. The major point being that sys.path has nothing to do with the PYTHONPATH environment variable. You now have an installation where you can be assured of no collisions, because you control it completely.
JimF, I am still trying to understand this. Gordon, Barry and I think a good solution is to put "Shared" on a private sys.path, but you object to this and I don't understand. Specifically zope/ zope/Shared zope/Shared/mx/... zope/Shared/AnotherPackage/... zope/Shared/some_file.py zope/ZopePackage1/... zope/ZopePackage2/... zope/bin/python.exe Suppose zope users must use the special binary zope/bin/python.exe. Suppose further that this binary reliably sets its sys.path to the directories it needs, namely zope, zope/Package*, zope/Shared. Suppose further that all user's packages must go into zope/Shared either as files or package directories and so are at the top level as package imports have always assumed. Then it seems that your zope app would absolutely work, and no other Python installation could damage it by changing PYTHONPATH, and that your zope installation would not damage any other Python installation either. Is the reason this doesn't work the posibility of name collisions in zope/Shared? I thought before that you were worried about name collisions in another co-existing Python installation which may have unknown packages installed, conflicting packages, or packages with incompatible versions. If so, you are trying to solve a problem more severe than I thought. I have always assumed packages would have unique names and so a flat name space suffices. In particular, trying to design for conflicting names can not be supported by the current python *.pyl library file design, and in general would require a PYTHONPATH mechanism. Such PYTHONPATH mechanism would have to be "local" to packages. That is, PYTHONPATH would vary depending on the package doing the importing. Are you sure this problem needs a solution right now? Jim Ahlstrom