This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Wrong initialization of python path with embeddable distribution
Type: enhancement Stage: resolved
Components: Windows Versions: Python 3.5
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: Denny Weinberg, eryksun, palm.kevin, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2016-07-14 22:50 by palm.kevin, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (5)
msg270447 - (view) Author: Palm Kevin (palm.kevin) Date: 2016-07-14 22:50
The way the python path is initialized with the embeddable python distribution makes no sense for me.

If no environment variable PYTHONPATH is set, then the path is initialized like this:
  [python352]\python35.zip;.\DLLs;.\lib;[folder_of_executable]
     --> the distribution folder itself is not in the path ([python352]), an import of _socket will thus fail !
     --> Having DLLs and lib in the path is useless
(Notice, that when the PYTHONHOME is initialized, then the path '[python352]' is also used for DLLs and lib (instead of '.\')


If the environment variable PYTHONPATH is set, then the path is extended like this:
  [python352]\python35.zip;[folder_of_executable]
     --> the distribution folder itself is not in the path ([python352]), an import of _socket will thus fail !

I would prefer this behavior:
* python path is not initialized anymore with 'DLLs' and 'lib' 
* the distribution-folder should always be added to the python-path
msg270449 - (view) Author: Palm Kevin (palm.kevin) Date: 2016-07-14 23:13
BTW: Is there a good reason, the folder-of-the-executable is added to the python-path? I don't see any...
msg270450 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-07-15 00:09
Environment variables shouldn't make any different to the embeddable distro - it is designed to ignore them. Have you modified it at all?

The path is not as clean as I'd like it to be, but the initialization changes necessary are too significant for 3.5 at this stage (expect something better for 3.6).
msg270454 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2016-07-15 01:33
It looks like you haven't copied pyvenv.cfg to your application directory, so Python isn't using the "applocal" configuration. That's why you're seeing the default paths that are relative to the current directory. It's also why PYTHONPATH and PYTHONHOME aren't ignored. 

As to the extension modules, if you don't want them in the application directory, add them to the DLLs subdirectory. Here's a possible layout:

	App\
	    DLLs\
		_socket.pyd
                ...
            Lib\
                vendored_package
		...
	    app.exe
	    pyvenv.cfg
	    python35.dll
	    python35.zip
	    vcruntime140.dll

I created this app in C:\Temp, and here's its sys.path:

    ['C:\\Temp\\App\\python35.zip', 'C:\\Temp\\App\\DLLs', 'C:\\Temp\\App\\lib', 'C:\\Temp\\App']
msg275539 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-09-10 01:53
This has changed for 3.6 and won't be changing again for 3.5. See https://docs.python.org/3.6/using/windows.html#finding-modules for info on the new support.
History
Date User Action Args
2022-04-11 14:58:33adminsetgithub: 71703
2016-09-10 01:53:08steve.dowersetstatus: open -> closed
resolution: out of date
messages: + msg275539

stage: resolved
2016-07-26 14:03:27Denny Weinbergsetnosy: + Denny Weinberg
2016-07-15 01:33:49eryksunsetnosy: + eryksun
messages: + msg270454
2016-07-15 00:09:05steve.dowersetmessages: + msg270450
2016-07-14 23:13:58palm.kevinsetmessages: + msg270449
2016-07-14 23:10:10ned.deilysetnosy: + paul.moore, tim.golden, zach.ware, steve.dower
components: + Windows
2016-07-14 22:50:14palm.kevincreate