classification
Title: Change the environment for a new process
Type: enhancement Stage: resolved
Components: Library (Lib), Windows Versions: Python 3.8
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: eryksun, josh.r, paul.moore, r-or, roufique7, steve.dower, tim.golden, zach.ware
Priority: normal Keywords: patch, patch, patch, patch

Created on 2019-01-30 19:45 by r-or, last changed 2019-02-02 16:35 by steve.dower. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 11705 closed r-or, 2019-01-30 19:59
PR 11705 closed r-or, 2019-01-30 19:59
PR 11705 closed r-or, 2019-01-30 19:59
PR 11705 closed r-or, 2019-01-30 19:59
Repositories containing patches
rtat.net
Messages (6)
msg334591 - (view) Author: Tobias Däullary (r-or) * Date: 2019-01-30 19:45
There should be a possibility to change the environment of a process created with multiprocessing.

For subprocess this is possible thanks to the "env" attribute.

Elaboration:
While it is trivial to change os.environ manually, in some cases this is not possible. 

For instance: creating a COM process on Windows; this process will always inherit the environment of the host process.
A workaround is to spawn a python process with a different environment which then will provide this to the child COM process.
msg334649 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2019-02-01 05:31
Why is not having the target assign to the relevant os.environ keys before doing whatever depends on the environment not an option?
msg334651 - (view) Author: Tobias Däullary (r-or) * Date: 2019-02-01 06:00
Because sometimes when a process is implicitly started by some 3rd party library (i.e. COM via pythonwin here) the "old", unchanged environment is retained as the process itself doesn't care if os.environ was changed or not, the original environment cannot be modified.

This solution would give a lot of flexibility in that regard.

I think pythonwin is actually a special case as the problem here lies somewhere in the dispatch(.) call. The process creation should be handled somewhere within the COM interface, pywin does nothing there. 

But this solution effectively circumvents that issue.
msg334656 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2019-02-01 08:42
> Because sometimes when a process is implicitly started by some 3rd 
> party library (i.e. COM via pythonwin here) the "old", unchanged 
> environment is retained as the process itself doesn't care if 
> os.environ was changed or not, the original environment cannot 
> be modified.

What "old" environment are we talking about? The os.environ mapping is implemented to immediately modify the process environment block. For example:

Python:

    >>> os.environ['SPAM'] = 'EGGS'

Debugger:

    Breakpoint 0 hit
    KERNELBASE!SetEnvironmentVariableW:
    00007fff`8ae3ee30 4053            push    rbx
    0:000> kc 6
    Call Site
    KERNELBASE!SetEnvironmentVariableW
    ucrtbase!common_set_variable_in_environment_nolock<wchar_t>
    ucrtbase!common_putenv_nolock<wchar_t>
    ucrtbase!common_putenv<wchar_t>
    python37!os_putenv_impl
    python37!os_putenv

    0:000> du @rcx
    00000215`70dd57c0  "SPAM"
    0:000> du @rdx
    00000215`70dd57ca  "EGGS"
msg334744 - (view) Author: Tobias Däullary (r-or) * Date: 2019-02-02 11:50
Alright, thanks for pointing me in the right direction.

I have to conclude that this issue is not present on a current operating system, as I now tried to reproduce with Windows 10 (I came across it on an ancient Windows XP (sic) system - I can just imagine putenv didn't do its job as requested).

I suppose this can be closed then!
msg334753 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-02-02 16:35
Among other things, the version of the C runtime you were using on that old system probably has its own set of bugs that have since been resolved.

Thanks for reporting the issue, though!
History
Date User Action Args
2019-02-02 16:35:33steve.dowersetstatus: open -> closed
messages: + msg334753

keywords: patch, patch, patch, patch
resolution: fixed
stage: patch review -> resolved
2019-02-02 11:50:37r-orsetmessages: + msg334744
2019-02-01 08:42:44eryksunsetkeywords: patch, patch, patch, patch
nosy: + eryksun
messages: + msg334656

2019-02-01 06:00:32r-orsetnosy: + zach.ware, paul.moore, tim.golden, steve.dower
messages: + msg334651
components: + Windows
2019-02-01 05:31:18josh.rsetkeywords: patch, patch, patch, patch
nosy: + josh.r
messages: + msg334649

2019-02-01 05:26:20josh.rsetmessages: - msg334593
2019-02-01 05:25:34josh.rsetfiles: - core-nix.snapshot.json
2019-02-01 05:25:24josh.rsetfiles: - bq-nix.snapshot.json
2019-02-01 05:25:00josh.rsetfiles: - bq-nix.manifest
2019-01-30 20:21:32roufique7setfiles: + bq-nix.manifest
hgrepos: + hgrepo379
2019-01-30 20:20:13roufique7setfiles: + bq-nix.snapshot.json
nosy: + roufique7
messages: + msg334593

2019-01-30 20:19:24roufique7setfiles: + core-nix.snapshot.json
2019-01-30 19:59:58r-orsetkeywords: + patch
stage: patch review
pull_requests: + pull_request11561
2019-01-30 19:59:55r-orsetkeywords: + patch
stage: (no value)
pull_requests: + pull_request11560
2019-01-30 19:59:52r-orsetkeywords: + patch
stage: (no value)
pull_requests: + pull_request11559
2019-01-30 19:59:48r-orsetkeywords: + patch
stage: (no value)
pull_requests: + pull_request11558
2019-01-30 19:45:16r-orcreate