[pywin32-bugs] [ pywin32-Bugs-1053745 ] PythonPath no longer set by installer.

[SourceForge.net <no...@so...>]

Bugs item #1053745, was opened at 2004-10-25 16:03
Message generated for change (Comment added) made by ogiesen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1053745&group_id=78018

Category: installation
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Oliver Giesen (ogiesen)
Assigned to: Nobody/Anonymous (nobody)
Summary: PythonPath no longer set by installer.

Initial Comment:
I have meant to report this ever since the first 20x
release but somehow never got around to it:

Before the 20x releases the installer used to add the
extensions to the PythonPath as sub-entries win32 and
win32com respectively. This no longer is the case and
as a result my WinCvs macros that make use of the
extensions no longer work unless I add the extensions
to the PythonPath manually. Is there something I have
missed? Is there some other way to make the extensions
"publicly importable" nowadays?

----------------------------------------------------------------------

>Comment By: Oliver Giesen (ogiesen)
Date: 2004-11-15 15:39

Message:
Logged In: YES 
user_id=158827

Ok, thanks to your hints the WinCvs developers were able to
fix this on their end. Issue closed. Thanks a lot!

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-11-05 04:50

Message:
Logged In: YES 
user_id=14198

It was removed as it causes problems when multiple
installations of Python exist on the same machine.  If one
application wants to include a 'private' Python in their
application directory, the global registry screws things. 
Removing these registry settings have solved many problems
for people.

If wincvs is using its own Python, then the current
behaviour is unfortunately correct.  There should be a way
to specify what dir you want to install pywin32 in, but
there isn't.  The solution is to simply copy those pywin32
directories, and the .pth file (which has relative paths) to
the cygwin python's site-packages directory.

If cygwin is using the "global" Python, then it probably
means cygwin is preventing site.py from running - this is
what locates and processes the .pth files.

I'm happy to help you resolve this, but am very unlikely to
move back to the registry.

----------------------------------------------------------------------

Comment By: Oliver Giesen (ogiesen)
Date: 2004-11-01 09:47

Message:
Logged In: YES 
user_id=158827

Yes, that file is there and it does obviously get taken into
account when I run Python scripts via python.exe, however,
that's not what I do most of the time. Most of the time my
scripts are run via Python23.dll (as macros embedded in
WinCvs) and AFAICT that does not take into account the
pywin32.pth file. This only works if the path is actually
set in the PythonPath registry key, i.e.
HKLM\SOFTWARE\Python\PythonCore\2.3\PythonPath .

I'm simply a bit confused because I'm really sure that I
never had to manually edit the PythonPath with the pre-200
installers. Was there a specific reason why this
functionality has been removed from the installers?
Or could this be a problem of the way WinCvs embeds Python?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-10-26 01:04

Message:
Logged In: YES 
user_id=14198

There should be a pywin32.pth file installed into your
site-packages directory.  Python loads this as it starts up
- unless you have told Python not to process site.py

You should be able to confirm this by running python.exe and
printing sys.path

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1053745&group_id=78018