
Jim Fulton wrote:
It actually does now, although that is bad. What if some future python distribution has a Products package? Or a Products.py?
Name it zopeProducts. Or Zope/Products and Zope/Shared.
A product is actually a sub-package of Products. Even if Products was not a package, the Product would be and gadfly and kjParsong would be sub-packages. There is a similar issue with Shared, since Shared software is organized by organization, as in 'Shared.DC.ZRDB'.
See below.
The point is that stuffing arbitrary things into a single global name space is bad. That's why packages were invented. Unless packages can be effectively nested, you haven't gained anything but time.
Packages nest effectively. Subpackages just don't masquerade as top level packages. [Barry]
A user would drop the kjParsing directory into Shared, and then all the import kjParsing.kjParser statements would Just Work.
But then they'd be dumping kjParsing into the global package namespace. Eventually, there will be collisions.
You are trying to do two incompatible things at once. You are trying to be both a standalone application, and a Python installation. You can be both, just not at the same time. 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. Of course, that will make liars out of the people at your company who claim you can mix and match pieces of Zope and your own stuff as you please. People who want to mix and match need Zope to play by normal Python rules - and that means packages are installed at the top level. Collisions happen, but your audience is people who *want* to do things differently and *want* control of their installations. By creating "self contained" packages and putting them in a normal Python installation, you're just pushing your headache off on the user. You're co-opting his installation. Yeah, now you have two versions, but they're 99% the same. Build the normal Python one first and distribute it to the hackers. Then install some import and startup hooks, and distribute that to your "users". I, for one, still use Bobo, because Zope doesn't play fair and I have no need or desire for yet another Python installation. - Gordon