On Tue, 14 Sep 1999, James C. Ahlstrom wrote:
Skip Montanaro wrote:
So I started looking around at the versions and dates of various copies of asynchat.py. ... What's apparently been happening is that people have picked up asyncore and asynchat at various time and stuck them in their own CVS repositories without somehow freezing the Id string of the version they originally got from Sam Rushing. It's not clear what the differences are until you compare the actual files. It turns out that the Zope 2.0 and Medusa versions have
Yes, I have had this happen too. I am unwilling and unable to risk this sort of problem at a customer's site. So I ship a complete app with no external dependencies. Also crude but effective.
We did the same with the Python-based apps/servers at Microsoft.
Merchant Server was a big frozen app (based on the non-sensical requirement to hide the fact that Python was used). In Site Server 2.0 and 3.0, we used a mini-install -- just the Lib files we needed plus our extensions.
In the Site Server (non-frozen) case, we did use the registry, but built the interpreter with a custom "version". SS20 and SS30. In the registry, this meant we used Python/PythonCore/SS20 (I think that's the layout).
Worked great, no complaints.
Oh, and the DLLs we put into the system directory (pretty necessary for COM) were named SS20<whatever>.DLL to prevent conflicts.
I'm not sure who said it, but I agree with the following statement:
* ship your app as a complete black box, or ship your app with dependencies on modules/packages [at the top level]
This monkeying around with "mx.foo" working where mx is at the top level or is embedded is just scary.
That said, personally, I would just do something like the following at the startup of my app:
[where ZopeImporter is a imputil.Importer subclass]
The importer would just Do The Right Thing for all imports, and only defer to the Python library for things that weren't shipped with Zope (the empty set?)
-- Greg Stein, http://www.lyra.org/