Replies: 3 comments
-
I believe pywin32 is not yet made to work in a virtual env. At least in my recent attempts (with 221) I had to install pywin32 as admin once. It had to put some dlls into a windows system dir. |
Beta Was this translation helpful? Give feedback.
-
Certainly some things work in a virtualenv (I had used Christoph Gohlke's wheels for some time before official pywin32 wheels were available, and never hit anything that didn't work). It would just be nice to have an official statement of when and why the postinstall script is needed, and what won't work without it. Currently the readme says "you almost certainly need to execute" the postinstall. That contradicts my experience, which is that a lot of the time you don't. As one specific case, I'd like to know if the COM client support works without the postinstall script - I'm fairly sure the server side COM stuff needs postinstall, but that's not as important to me. I'm going to respond here since my account is currently flagged so that you can see my response. The postinstall script does not work with virtual environments at all. Rather, it alters the system DLL search path to pick up the pywin32 DLLs. I've submitted gh-1153 (which you probably cannot see) (which is essentially the pypiwin32 search path fix) so that pywin32 will work with virtual environments. |
Beta Was this translation helpful? Give feedback.
-
Note that the comment about "you must execute the post-install script" was more about the fact the DLLs aren't in the right spot. #1153 should fix that - I intend installing an additional .pth file when installed from a wheel. Apart from that, client support should work fine. I'll close this out in favor if #1153. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The readme mentions:
It's not clear how this interacts with use of pywin32 from within a virtualenv, or with uninstallation. Can this be clarified (and if needed, support be added)?
Specifically:
Note that for (2) and (3), I'd be perfectly happy for 99% of use cases to simply have a clearly documented list of "things that don't work without postinstall", combined with a note that the postinstall should not be run in a virtual environment. While it would be nice to (for example) host a service in a virtualenv, it's not something I explicitly need, whereas firing up a temporary virtualenv, installing some packages in it, using them, and then deleting it, is something I do routinely.
Beta Was this translation helpful? Give feedback.
All reactions