[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

STINNER Victor added the comment: I read again the issue. In short, the Path Configuration is a mess and unusable in some cases :-) I reopen the issue. Handling venv shouldn't be handled by the site module which is optional, but earlier. I guess that venv support was added to site because

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Mario added the comment: Unfortunately the underlying cause of this issue has not been addressed, nor discussed. There is now a way to workaround the different behaviour in Windows and Linux and it is possible to use the new call to make virtual environment work in Windows as they already

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

STINNER Victor added the comment: I understand that issue is now fixed in bpo-36763 by the implementation of the PEP 587 which adds a new public API for the "Python Initialization Configuration". It provides a finer API to configure the "Path Configuration". For example, PyConfig.executable

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: The next releases of 3.7 and 3.8 will include _Py_SetProgramFullPath() functions for embedders to set the eventual value of sys.executable before calling Py_Initialize(). It's undocumented and not guaranteed stable (and indeed, it looks like Victor is already

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: New changeset 177a41a07b7d13c70d068ea0962f07e625ae171e by Steve Dower in branch 'master': bpo-34725: Adds _Py_SetProgramFullPath so embedders may override sys.executable (GH-9860)

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: New changeset e851049e0e045b5e0f9d5c6b8a64d7f6b8ecc9c7 by Steve Dower in branch '3.7': bpo-34725: Adds _Py_SetProgramFullPath so embedders may override sys.executable (GH-9861) https://github.com/python/cpython/commit/e851049e0e045b5e0f9d5c6b8a64d7f6b8ecc9c7

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: I requested Victor review on my PR, but if anyone else is able to please feel free. -- ___ Python tracker ___

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Mario added the comment: On 13/10/2018 17:37, Steve Dower wrote: > > Steve Dower added the comment: > > I meant why are you using an embedded application with a virtual environment? > What sort of application do you have that requires users to configure a > virtual environment, rather

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Change by Steve Dower : -- versions: +Python 3.8 -Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Change by Steve Dower : -- pull_requests: +9230 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Change by Steve Dower : -- keywords: +patch pull_requests: +9229 stage: -> patch review ___ Python tracker ___ ___

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: I meant why are you using an embedded application with a virtual environment? What sort of application do you have that requires users to configure a virtual environment, rather than providing its own set of libraries? The embedding scenarios I'm aware of

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Mario added the comment: On 10/10/2018 01:11, Steve Dower wrote: > > Steve Dower added the comment: > > We'll need to bring in venv specialists to check whether using it outside of > Py_Main() is valid. Or perhaps you could explain what you are actually trying > to do? > Sure 1) Create

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: We'll need to bring in venv specialists to check whether using it outside of Py_Main() is valid. Or perhaps you could explain what you are actually trying to do? I don't believe it is necessary when you are calling Py_SetPath yourself, and only the "launch

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Mario added the comment: On 08/10/2018 17:54, Steve Dower wrote: > > Steve Dower added the comment: > >> Py_SetProgramName() should be a relative or absolute path that can be used >> to set sys.executable and other values appropriately. > > Key point here is *can be*, but it doesn't have

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: > Py_SetProgramName() should be a relative or absolute path that can be used to > set sys.executable and other values appropriately. Key point here is *can be*, but it doesn't have to be. Given it has fallbacks all the way to "python"/"python3", we can't

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Nick Coghlan added the comment: Directly addressing the topic of the bug: Py_SetProgramName() should be a relative or absolute path that can be used to set sys.executable and other values appropriately. This is used in Programs/_testembed.c for example. I didn't know it didn't work the

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Change by Steve Dower : -- nosy: +eric.snow, ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: Reading the docs, I'm pretty sure we need a new Py_SetProgramFullPath() function. Py_SetProgramName explicitly is only providing a hint to figure out the file containing the executable, and I really want this to make my new launcher feasible:

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: I don't think anything has been agreed upon. Currently, the launched program name is used for some things other than setting sys.executable, and I believe it should continue to be used for those. But there are also needs for overriding sys.executable to be

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Mario added the comment: Is there any agreement on what is wrong with the current code. The key in my opinion is the double purpose of sys.executable and that in Linux and Windows people have taken the two different points of view, so they are both right and wrong at the same time.

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Mario added the comment: On 21/09/2018 21:44, Steve Dower wrote: > > Steve Dower added the comment: > > I meant returning the full name of the process is intentional. But you're > right that overriding it should actually override it. > > I found the prior bug at issue33180, but I'm

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: I meant returning the full name of the process is intentional. But you're right that overriding it should actually override it. I found the prior bug at issue33180, but I'm closing it in favour of this one. I don't have fully fleshed out semantics in my mind

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Mario added the comment: On 18/09/2018 19:24, Steve Dower wrote: > > Steve Dower added the comment: > > That executable doesn't appear to be in a virtual environment - you should be > running C:\TEMP\venv\abcd\Scripts\python.exe > > Does that resolve your problem? > Nope, I am *not*

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: (Also, the behavior of Py_GetProgramFullPath is intentional, but we do have another bug somewhere to be able to override it for embedding purposes. sys.executable should be None when it does not contain a suitable path for running the normal Python interpreter

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: That executable doesn't appear to be in a virtual environment - you should be running C:\TEMP\venv\abcd\Scripts\python.exe Does that resolve your problem? -- ___ Python tracker

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

New submission from Mario : According to the doc Py_GetProgramFullPath() should return the full path of the program name as set by Py_SetProgramName(). https://docs.python.org/3/c-api/init.html#c.Py_GetProgramFullPath This works well in Linux, but in Windows it is always the name of the