"James C. Ahlstrom" wrote:
Jim Fulton wrote:
In this context, consider the following concrete, though fictional example. ............
The classical solution would be to add "Shared" to sys.path. But how to do this? And what if another installation changes it?
This doesn't work, because 'Shared' has sub-packages by organization.
I'd be curious to hear how folks would solve this problem.
1) Ship a custom binary interpreter with critical modules frozen in, and which sets a custom sys.path before anything else happens. So you are not dependent at all on PYTHONPATH. Currently this works.
This is what we do for our binary distribtions, but it doesn't do anything for third-party products added to Zope.
2) Add a new command line option which sets sys.path and always use it to start your app. It lists only critical zope directories so zope has its own private name space.
We have a start script that takes care of this. This gets Zope's top-level names (of which there are too many already) into the path. This doesn't help with third-party products added to Zope.
3) Add your own import hooks using imputil.py and boot it as in (1).
But imputil has a global effect. I suppose I could implement what I want with imputil or by otherwise creating my own importer using the standard import hooks. I suspect that's what I'll have to do eventually.
Better if it were part of Python. 4) Use a new Python.pyl file which has seeking from the end and thus allows concattenation of multiple *.pyl. Each package is a foo.pyl, bar.pyl, and to distribute an app, you concatenate packages. The implied PYTHONPATH in each *.pyl file is "." except perhaps for the Python lib which is "Lib". Boot it as in (3).
I'm not looking for a way to replace the current package scheme. Also, I'm not just looking at an app, but at an app that contains apps (aka components).
Personally, I'd like the problem to go away. :)
I have the same problem, so me too.
I'd like the Python import rules to change to make this solvable without import hooks or path hacking. I can think of two ways to approach this:
- Relative parent imports:
import __.kjParsing.kjParser
OK by me, but doesn't solve the Grand Problem.
- Gradually less local searches.
I am currently bewildered by Python's import mechanism, and this may push me into brain damage. Well, *more* brain damage.
I don't see what's so complicated. You just use a gradually widening search, rather than an immediately widening search. I don't think that this is any more complicated than the current rule. I actually prefer the second apprach because it doesn't require any code changes to take advantage of it. I may implement it for Zope if nothing is done in standard Python. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.