[Python-Dev] Re: .DLL vs .PYD search order

[James C. Ahlstrom]

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