Tkinter sets the HOME environment variable, breaking scripts

[JarrodPetz]

BPO	27263
Nosy	@terryjreedy, @pfmoore, @tjguk, @roseman, @zware, @serhiy-storchaka, @eryksun, @zooba

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2016-06-08.02:24:47.726>
labels = ['type-bug', 'expert-tkinter', '3.9', '3.10', '3.8', 'OS-windows', 'docs']
title = 'Tkinter sets the HOME environment variable, breaking scripts'
updated_at = <Date 2021-02-26.17:51:17.548>
user = 'https://bugs.python.org/JarrodPetz'

bugs.python.org fields:

activity = <Date 2021-02-26.17:51:17.548>
actor = 'eryksun'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation', 'Tkinter', 'Windows']
creation = <Date 2016-06-08.02:24:47.726>
creator = 'Jarrod Petz'
dependencies = []
files = []
hgrepos = []
issue_num = 27263
keywords = []
message_count = 14.0
messages = ['267761', '267762', '267770', '267794', '268169', '268176', '268180', '268181', '268190', '268195', '268292', '268476', '268496', '387733']
nosy_count = 10.0
nosy_names = ['terry.reedy', 'paul.moore', 'tim.golden', 'markroseman', 'docs@python', 'zach.ware', 'serhiy.storchaka', 'eryksun', 'steve.dower', 'Jarrod Petz']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue27263'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

Linked PRs

• gh-71450: Document that Tcl sets the HOME variable on Windows #152568
• [3.15] gh-71450: Document that Tcl sets the HOME variable on Windows (GH-152568) #152574
• [3.14] gh-71450: Document that Tcl sets the HOME variable on Windows (GH-152568) #152575
• [3.13] gh-71450: Document that Tcl sets the HOME variable on Windows (GH-152568) #152576

[JarrodPetz]

It seems IDEL is setting the environment variable 'HOME' on windows. Specifically I am on windows 8.1

This is extremly annoying and bad as according the code and doco, os.path.expanduser will preference this variable above others such as USERPROFILE.
https://docs.python.org/3/library/os.path.html#os.path.expanduser

This is causing scripts/libraries and in my case the AWS SDK boto3/botocore modules to break. As they are looking for config files in the users home location using os.path resolution order which should be %USERPROFILE% in my case as I don't have HOME set. But because idle is setting HOME to what looks to be my HOMEPATH and HOMEDRIVE this is making the AWS SDK unable to pickup the credential files required.

path = "~/.aws/credentials"
print(os.path.expanduser(path))

Should be
C:\Users\myUserName/.aws/credentials

But is instead
H:\/.aws/credentials

Please stop IDLE from setting this environment variable. Running the same scripts with python.exe or pythonw.exe works fine.

[JarrodPetz]

It also makes things none deterministic. As when I am off the domain or my network drive H:\ is unavailable it works and uses USERPROFILE.

[JarrodPetz]

Worked around this by setting HOME to be USERPROFILE before IDLE starts

Rather then change the system/user environment permanently. I edited the Idle script which the windows shortcut seems to run below.

C:\Python35\Lib\idlelib\idle.pyw

At the top of the script I added
------------------------------------

import os
os.environ['HOME'] = os.environ['USERPROFILE']

---

[eryksun]

This affects all Tkinter applications on Windows. For example, in Python 2.7:

    import Tkinter
    import ctypes
    libc = ctypes.CDLL('msvcr90')
    libc.getenv.restype = ctypes.c_char_p

    >>> libc.getenv(b"HOME")
    >>> root = Tkinter.Tk()
    >>> libc.getenv(b"HOME")
    'C:\\Users\\me'

TCL sets this environment variable in TclpSetVariables 1 and has since 1995 2. I don't think IDLE or any other Tkinter application should necessarily favor %USERPROFILE% over %HOMEDRIVE%%HOMEPATH%, and the default shouldn't be changed at this point. Probably the behavior should be documented for Tkinter and IDLE.

[terryjreedy]

As IDLE maintainer, this annoys me also. IDLE and in particular test_idle necessarily change the environment by calling tkinter.Tk(). When run under test.regrtest, test_idle gets slapped with a warning, and in 3.6, gets labelled a failure, even when it passes.

This issue cuts the other way too. IDLE works for months and then stops working. User posts "IDLE stopped working' on Stackoverflow. In at least some cases, user installed a program that installed ab incompatible tcl/tk and set TCL_LIBRARY (which Python does not). tk and tkinter get trapped by what for us is a bad setting.

Serhiy, could the _tkinter startup code recover from this and revert to using the one we installed? Should I open a separate issue?

[serhiy-storchaka]

What is the problem? That user sets incorrect TCL_LIBRARY? I don't know how _tkinter can distinguish correct TCL_LIBRARY from the incorrect one.

[terryjreedy]

Python does not set TCL_LIBRARY. _tkinter finds tcl/tk installed with Python at its known location for the platform. tkinter and IDLE work fine for months. Then user installs another program. That other software (not user, and unbeknownst to the user) sets TCL_LIBRARY to something that _tkinter cannot use. I am guessing that _tkinter, seeing TCL_LIBRARY, tries to use alternate install, cannot, and gives up, instead of falling back to the python-tcl it was using for months.

[serhiy-storchaka]

This is Windows specific issue, I can't help with this, sorry. Zach should be more experienced in this.

[zware]

For the original issue, I agree with Eryk that about the best we can do is to document that Tcl sets HOME as "%HOMEDRIVE%%HOMEPATH%" or "c:\" if both of those are not set. I wonder about removing (or de-preferring) HOME in os.path.expanduser, but that would be a significantly backward incompatible change. Since HOME is not set by default on Windows, setting it is the easiest way to manipulate os.path.expanduser, and changing it is going to break things.

The TCL_LIBRARY issue is completely separate. I rewrote the logic that used to be in tkinter._fix for 3.5, it's now a part of _tkinter initialization and TCL_LIBRARY is no longer set (permanently) by tkinter (TK_LIBRARY is not set or inspected at all anymore, except by Tk itself). I did this in an effort to avoid the environment warnings in the tkinter/IDLE tests, but apparently missed the HOME issue at that point.

Anyhow, we could theoretically unset TCL_LIBRARY (and TK_LIBRARY) in that initialization code, possibly conditional on whether TCL_VERSION can be found in the content of TCL_LIBRARY (the assumption being that a library for the same major version of Tcl ought to work anyway). However, without that conditional, that would be another big backward compatibility issue; setting {TCL,TK}_LIBRARY is a legitimate way to point tkinter towards a non-standard Tcl/Tk library location (e.g. in an embedding situation). With conditional clearing of {TCL,TK}_LIBRARY, we're still at the mercy of a just plain bad setting that just happens to contain the magic string that makes it look acceptable.

I'm -1 on making such a change anyway. We've avoided permanently setting TCL_LIBRARY for many many years, other applications can figure out how to avoid it as well. We can't try to clean up messes made by other badly behaved programs, that way lies madness.