[ZCM] [ZC] 1711/ 7 Comment "Zope on Windows installs PyWin in non-standard folder structure"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #1711 Update (Comment) "Zope on Windows installs PyWin in non-standard folder structure"
 Status Pending, Zope/bug medium
To followup, visit:
  http://www.zope.org/Collectors/Zope/1711

==============================================================
= Comment - Entry #7 by mgf on Jul 19, 2005 3:06 pm

I can confirm this works ok now in 2.7.7, with thanks!

Martin
________________________________________
= Comment - Entry #6 by tim_one on Jul 11, 2005 10:46 am

You shouldn't have had a problem with Zope 2.7.7 -- 2.7.7 incorporates Mark Hammond's build patches, and installs pywin32 build 204 in a standard way.
________________________________________
= Comment - Entry #5 by PatrickD on Jul 11, 2005 5:38 am

Thanks, reinstalling PyWin solved this problem with Zope 2.7.7 for me.

For some reason, I did not meet this problem with Zope 2.7.2 and 2.7.5.

Regards,
Patrick.
________________________________________
= Comment - Entry #4 by mgf on Feb 24, 2005 10:30 am

Thanks. I cannot rely on the registry key thing, however, as we need multiple independent installations on one server. As a stop-gap, I patch sys.path manually in sitecustomize.py, but I don't like that too much... 

Best regards, Martin
________________________________________
= Comment - Entry #3 by tim_one on Feb 24, 2005 10:25 am

The repackaging of win32all inside Zope is indeed insane.  FYI, it's a result of that using win32all's older Wise installer, and asking it just to extract the files (Wise supports a command-line switch for this), the Wise installer itself destroys the intended directory structure.  Whoever wrote this part of Zope's Windows buildout didn't notice this, because Zope in fact uses very little from win32all, and the little it uses just happens to work fine anyway.

Mark Hammond submitted patches to do a correct job of installing win32all (somewhere in the Collector ... can't look now).  Nobody yet has volunteered to incorporate them, though.

Something that _might_ work for you:  try installing win32all in the normal way, i.e. just run its installer, and let it install into your own Python installation.  It's quite possible that your installation of win32all will shadow Zope's then (and despite that Zope's Python shadows yours):  a normal win32all install creates registry keys that force whatever Python is running to put that win32all's directories early in sys.path.  That's a bug too (from Zope's POV), but one you may be able to exploit until Zope repackages win32all sanely.

________________________________________
= Comment - Entry #2 by mgf on Feb 24, 2005 10:19 am

Martin Gfeller, COMIT: Anonymous User 
Sorry, didn't mean to be anonymous :-) 
My Zope.org Id is mgf. 
Martin
________________________________________
= Request - Entry #1 by Anonymous User on Feb 24, 2005 10:13 am

The Zope Windows Installer installs a copy of PythonWin (PyWin) into <Zope>\bin\Lib\site-packages. It seems to put all files of PyWin into that directory, without any substructure.

The standard PyWin installer (from SourceForge), however, uses subdirectories such as Pythonwin, win32, win32com, win32comext. 

Since Zope doesn’t follow this structure, an independent upgrade of PythonWin into <Zope>\bin\Lib\site-packages leads to duplication of files, fragile path dependencies, and much confusion. 
As Zope 2.7.3 does not contain the latest released PyWin version, I need to upgrade PyWin because I wanted to make use of some of its newer features. 

I think Zope should (i) follow the PyWin directory structure and (ii) be packaged with the then-latest release of PyWin.

Thanks! Martin
==============================================================