Gordon McMillan wrote:
Jim Fulton wrote:
(snip)
Packages nest effectively. Subpackages just don't masquerade as top level packages.
They do currently when imported from the containing package.
[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.
We don't try to be a Python installation. We try to be a Python application that is a platform for Zope applications.
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.
Zope reuses *alot* of code. I think Zope has a pretty good track record of working with existing code.
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.
Sorry, I just don't buy that.
Collisions happen, but your audience is people who *want* to do things differently and *want* control of their installations.
Actually, many Zope user's come to Python by way of Zope. They want to be able to install Zope products without worrying about what their zope or python installation looks like. Zope developers want to be able to have their products drop into a Zope installation easily.
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.
No, putting packages in the python path coops their installation. Putting Zope-specific products that happen to include reusable Python packages in a Zope-specific package leaves their installation alone.
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".
This is exactly what I want to prevent. I'd like package developers to develop their packages once without making them use esoteric import hooks. OTOH I'd like to be able to *use* their packages wherever I damn well please. I don't to be forced to put their packages in the python path.
I, for one, still use Bobo, because Zope doesn't play fair
In what way does Zope not play fair?
and I have no need or desire for yet another Python installation.
Cool. You don't need to use another Python installation to use Zope. In fact, for development, we use a totally standard Python distribution. Developers here are not *allowed* to add anything special to the Python installations on the development machines here because we want to *make sure* that we can run with stock python installations. 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.