Guido van Rossum wrote:
You must not have used the standard Python installer; if you had used it you wouldn't have had this problem (and perhaps we wouldn't have had this discussion).
Correct, I did not use the standard Python installer. I compiled Python from the source distribution. There are good reasons for this in my case. First, my real issue is how to DISTRIBUTE Python programs, not to get Python working on my own machine. We have 12 machines on a network. It is not acceptable to run a Python installation script on every one of them just to run a simple Python program. OK, I guess I could do 12, but what about a larger company? And we ship to hundreds of customers. I can distribute simple C or C++ programs without a hassle, why not Python? It is not acceptable to ask our customers to run a separate Python installer. We have our own Wise installer to install our software. Every commercial vendor has Wise, Install Shield or other installer in place. No commercial vendor is going to abandon Wise et al. and move to The Official Python Installer because it will not have the features of Wise (such as binary patches across the network), and because what it does won't be documented, and because it is Just Different. Second, I can not run ANY installer on my development machine, Python or otherwise. This is a general Windows problem not specific to Python. Right now our help system is broken on every office machine except the one where the help system installer was run (where we develop help). If I run a Python installer, it may Just Work here. So testing is fine, but when I distribute the program to customers where the install program has not been run it fails. The installer made registry entries, installed files, etc. And what did it do?? No one knows. And how do I install at a customer site if I don't have documentation on what the Help installer or Python installer did?? No one knows. Who fixes it if something goes wrong?? Hours on the phone to Help System customer support. Does it work on Windows 2000?? No one knows.
f:\bin. "Modern" Python versions execute some code at startup that comes up with a suitable value for sys.path; the Windows version of this code is in PC/getpathp.c -- I recommend that you study it. This
[ Highly useful discussion of startup...]
Thank you, I will study this.
know about (e.g. PIL, Numeric, etc.). With packagized versions of those modules, even that won't be necessary, because the packages will be dropped in the Python install directory (typically C:\Program Files\Python).
Yes, this is essential. Packages must be easily installed. I was hoping for single file package archive files.
I believe that most of your desire to get rid of PYTHONPATH comes from your insistence to bypass the default installer.
Correct, I refuse to execute the default installer. And I am a patient person who loves Python, so I will read getpathp.c to see what is happening. But other commercial developers, students, teachers, SysAdmins etc. are not so patient. In the interest of promoting Python, there should be documentation on the official way to easily install Python programs.
There's probably a way to install your app in such a way that the getpathp.c algorithm actually succeeds? There's also a separate env variable, PYTHONHOME,
Perhaps, and if there is it should be prominently documented in the How to Distribute Your App section of the manual. I am worried about supporting versioning, but I will think about it.
I take blame for not documenting all this well enough. However I wish you stopped criticizing the design -- I think the design is quite solid.
Thank you for the explanation. I will study the design again. I always wondered what PYTHONHOME did. JimA