Python Win installations and PYTHONPATH Confusion (WAS: Re: Python Path Blues)

[Tim Peters]

[Maan Hamze]
> The doc for DCOracle2 instructs the user to use PYTHONPATH.

I assume that worked, so no problem there.

> The doc for mxODBC does not, but instructs the user to use sys.path
> I used the sys.path for mxODBC and it did not work.  So I added it to
> PYTHONPATH envar and it worked.
> So of course I am confused :)

It could be that you're not confused enough yet <0.9 wink>.  The only effect
PYTHONPATH has on sys.path is to add its directories near the start of
sys.path, so you *should be* able to get exactly the same effect by losing
PYTHONPATH and fiddling sys.path yourself.  You should contact Marc-Andre
Lemburg and sort out why following his mxODBC instructions didn't work for
you.

Perhaps better, beginning with 2.2a2, the PythonLabs Windows installer
creates a Lib\site-packages directory, and site.py adds that to sys.path.
This is, much as on Unix too, intended to be "the normal" place for
extensions to install themselves (and then they'll be on sys.path without
further fiddling).

>>> 1.  Upon installing Python (PythonWin or the regular Python
>>> distribution for Windows), the registry itself is updated with the
>>> lib path,

>> It is, but please note that Python never *looks* at this
>> setting in normal operation.

> Ok!  what setting does it look at then when one adds some library into
> its own subdirectory and when one uses the import lib command to use
> something from that lib?

Sorry, I tried several times but couldn't parse that question.

> sys.path?  is it the sure way?

sys.path is the only thing ever looked at after Python initializes itself.
The only effect PYTHONPATH (or even the registry under extreme cases) has is
to add directories to sys.path at Python initialization time.  Something is
found if and only if it's present on sys.path.  But this is in the absence
of import hooks, the "clever" use of which can make things arbitrarily more
complicated than they're intended to be.

> Or is it to follow the instructions that comes with the package?

There's no limit to how perverse extension authors can get, so of course you
should follow their instructions.

> Maybe I ran into some bad luck then?

Don't know but suspect so.

> Since DCOracle2 and mxODBC did not behave as expected.

At the start of the msg I thought you said DBOracle2 said to use PYTHONPATH,
and implied that it worked.  Whatever, I don't care about sorting out what
you did and didn't intend to say or imply <wink>, so long as it's working
now.

> Well, they are working now, but it bothers me that I had to go into all
> this trouble to make them work :)

You shouldn't have to, of course.  When packages come with instructions that
don't work, the cure is to ask the package authors to fix their
instructions.  Note that there are a large number of import-related gimmicks
a package author *can* use, so it's not realistic to expect all package
authors to do things the same way.  In time, all packages will use
distutils, and you'll never have to think again <ahem>.