Found a inconsistent sys.path result when python packed with it's library with zip package.

A. when NOT use zip package
   sys.path is base the python.exe's absolute path, result is 
        1. ABS_PATH\pythonXX.zip
        2. ABS_PATH\DLLs
        3. ABS_PATH\lib, 
        4. ABS_PATH
        5. ABS_PATH\lib\site-packages

B. when use zip package
   sys.path is base the relative path of call path, result is 
        1. ABS_PATH\pythonXX.zip
        2. RLT_PATH\DLLs
        3. RLT_PATH\lib, 
        4. ABS_PATH

this is not commonly expected for the `DLLs` and `lib`, I think
the result will still be absolute path for where the executable
located. 

I snapshot two pictures for this problem, please review this,
thanks.

second snapshot

Windows Python determines sys.prefix (i.e. the location of the standard library, <prefix>\lib) via either the PYTHONHOME environment variable or by searching for the landmark "lib/os.py", starting in the application directory and reducing back to the root directory [1]. 

If it can't find the prefix directory; PYTHONPATH isn't defined; and it can't find PythonPath in the registry; then it adds the "DLLs" and "lib" directories relative to the working directory. This default PYTHONPATH is defined in PC/pyconfig.h as ".\\DLLs;.\\lib".

There is an alternative "applocal" (application local) mode. Create a file named pyvenv.cfg beside python.exe that contains the single line 

    applocal = true

This prevents Python from checking PYTHONHOME and PYTHONPATH, the registry, and prevents searching for the "lib/os.py" landmark. sys.prefix is set as the application directory, and the default "DLLs" and "lib" paths are expanded relative to the application directory.

Anyway, since what you're reporting is the expected behavior, I'm closing this issue. Feel free to reopen it if you feel I've misdiagnosed the problem or think the default behavior is somehow broken. I don't know what Steve Dower's plans are, if indeed he has any, to change the legacy sys.path behavior in future releases.


[1]: The reduce() function in PC/getpathp.c has a minor bug that
     results in sys.prefix set as the drive-relative path "C:" if 
     the landmark search continues to the root and "C:/lib/os.py" 
     exists. This is due to the way it overwrites the path separator 
     with NUL to reduce the path. I think it should keep the 
     separator. The join() function works either way.

Yea, thanks for review, I knew the pyven. But the behavior right now is
really what I think unnecessary complicated and confusing.
What I think, we all knew the DLLs is used for python keep the *.pyd
(actually just dll), so by default, why we want this directory
relative to the working directory? indeed the configure file can fix this,
but is this process really what we needed? we need check
the PYTHONHOME , read the registy, check if the configure file exist, just
for make python find the libraries?  I knew python has
a long history for keep the library path environment variable work right,
and not even mention pyenv and some other tools, but this
just make things more complicated.

So, as a conclusion, I think we should make the sys.path consistent with or
without using zip packed library, especially for the DLLs
if we think about some backward compatibility.fix this is just a small step
for making python application launch faster and packing simpler.

Thanks, I think this problem still arguable.

On Sat, Aug 27, 2016 at 17:38 Eryk Sun <report@bugs.python.org> wrote:

>
> Eryk Sun added the comment:
>
> Windows Python determines sys.prefix (i.e. the location of the standard
> library, <prefix>\lib) via either the PYTHONHOME environment variable or by
> searching for the landmark "lib/os.py", starting in the application
> directory and reducing back to the root directory [1].
>
> If it can't find the prefix directory; PYTHONPATH isn't defined; and it
> can't find PythonPath in the registry; then it adds the "DLLs" and "lib"
> directories relative to the working directory. This default PYTHONPATH is
> defined in PC/pyconfig.h as ".\\DLLs;.\\lib".
>
> There is an alternative "applocal" (application local) mode. Create a file
> named pyvenv.cfg beside python.exe that contains the single line
>
>     applocal = true
>
> This prevents Python from checking PYTHONHOME and PYTHONPATH, the
> registry, and prevents searching for the "lib/os.py" landmark. sys.prefix
> is set as the application directory, and the default "DLLs" and "lib" paths
> are expanded relative to the application directory.
>
> Anyway, since what you're reporting is the expected behavior, I'm closing
> this issue. Feel free to reopen it if you feel I've misdiagnosed the
> problem or think the default behavior is somehow broken. I don't know what
> Steve Dower's plans are, if indeed he has any, to change the legacy
> sys.path behavior in future releases.
>
>
> [1]: The reduce() function in PC/getpathp.c has a minor bug that
>      results in sys.prefix set as the drive-relative path "C:" if
>      the landmark search continues to the root and "C:/lib/os.py"
>      exists. This is due to the way it overwrites the path separator
>      with NUL to reduce the path. I think it should keep the
>      separator. The join() function works either way.
>
> ----------
> nosy: +eryksun
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue27874>
> _______________________________________
>

I don't know how to reopen this issue, please make some comments for 
what I added just now, thanks.

I don't entirely agree with the analysis or suggestions here, but I do intend to change this for 3.6 so I'll assign myself. At the very least, we won't fall back on totally relative paths - we'll make them absolute from the program directory.

thanks for the comment and make python work on Windows better :)
I will trace the 3.6 source code.

On Sat, Aug 27, 2016 at 8:58 PM Steve Dower <report@bugs.python.org> wrote:

>
> Steve Dower added the comment:
>
> I don't entirely agree with the analysis or suggestions here, but I do
> intend to change this for 3.6 so I'll assign myself. At the very least, we
> won't fall back on totally relative paths - we'll make them absolute from
> the program directory.
>
> ----------
> assignee:  -> steve.dower
> resolution: not a bug ->
> stage: resolved -> needs patch
> versions: +Python 3.6 -Python 3.5
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue27874>
> _______________________________________
>

For 3.6 I've changed this behaviour fairly significantly. See https://docs.python.org/3.6/using/windows.html#finding-modules for the new docs on the 'sys.path' file (name subject to change, but I like the parallel :) )

The embedded distro will include a default sys.path file with "python36.zip" and "." in it, which will omit the other entries. It's not ideal for "portable terminal" use as it enables isolated mode by default, but it's perfect for embedding.

I think I'll also make pythonXX.zip a landmark file (currently only Lib\os.py is checked), so that we default to the current path if the zip file is there.

New changeset 672c5fe7372c by Steve Dower in branch 'default':
Issue #27874: Allows use of pythonXX.zip file as landmark on Windows
https://hg.python.org/cpython/rev/672c5fe7372c

I noticed someone use `plat-win` instead of `DLLs` in this http://bugs.python.org/issue28046, so what's your opinion for this?
`plat-win` looks more meaningful than old `DLLs` at least for me,
do your have any plan for this in the 3.6 release?

I don't intend to change any defaults arbitrarily, but you can easily specify a folder with whatever name you like for these. I agree it would be a more sensible name, but it's such a minor issue that change would be more disruptive than helpful.

Yeah it's true, anyway thanks for your support
On Sat, Sep 10, 2016 at 22:10 Steve Dower <report@bugs.python.org> wrote:

>
> Steve Dower added the comment:
>
> I don't intend to change any defaults arbitrarily, but you can easily
> specify a folder with whatever name you like for these. I agree it would be
> a more sensible name, but it's such a minor issue that change would be more
> disruptive than helpful.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue27874>
> _______________________________________
>

Joseph: "plat-win" was actually removed from the comment in #28046; it is an obsolete name that hasn't been used since August 21, 2000.  I just killed the platform directories, let's not bring them back :)

Oh, can't believe this, and I thought iPhone 8 will bring back my lovely
3.5mm jack ^_^

On Sat, Sep 10, 2016 at 22:16 Zachary Ware <report@bugs.python.org> wrote:

>
> Zachary Ware added the comment:
>
> Joseph: "plat-win" was actually removed from the comment in #28046; it is
> an obsolete name that hasn't been used since August 21, 2000.  I just
> killed the platform directories, let's not bring them back :)
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue27874>
> _______________________________________
>