Jason R. Coombs <jar...@jaraco.com> added the comment: > Platform differences can be papered over with functions.
I’m not suggesting that from within Python there should be another way to detect a home directory. The expanduser functionality as written is just fine for that, though I agree with Steve that using an API on Windows would be even better. The issue is that from outside Python there’s now no platform-agnostic way to override the home directory, either for tests or to suppress user-local configuration. In addition to the test case, there is a user-facing use-case that's made more complicated: - A user needs to bypass the logged-in user's state for a Python command. For example, there was a buggy release (of something) that stored some broken state in the users’ home dir, and the workaround is to run some command with an alternate home dir. Communicating that technique to a multi-platform audience is now much more difficult. It was previously difficult enough because “set an environment variable” is a shell-dependent operation, so already requires the user to have some expertise on how to set environment variables in their environment. This change requires the guidance to be more complicated or for the expertise to be greater. > Breakage due to HOME being overridden is serious because it won't show up in > any other cases - Python will be the first to suffer the consequences Evidence is to the contrary. It seems other tools like 'git' honor the HOME directory: PS C:\Users\jaraco> $env:HOME = "C:\Users\jaraco\temp" PS C:\Users\jaraco> git config --global --list fatal: unable to read config file 'C:/Users/jaraco/temp/.gitconfig': No such file or directory Interestingly, I notice that Powershell does set the $HOME environment variable on Windows, reinforcing the concept that $HOME is a platform agnostic way to communicate a home directory. It does appear as if [Ruby honors HOME and sets it if unset on Windows](https://stackoverflow.com/a/13670703/70170). I'm not a fan of setting the variable, but there is precedent. It seems to me Python 3.8 is the outlier and that honoring $HOME, while somewhat awkward on Windows, was a valuable unifying behavior, and its removal without any plans for a replacement is causing harm. Just searching through some of the projects I have checked out, I find a few. Here's [another real-world example relying on Python honoring HOME to override home](https://github.com/jaraco/path/blob/7789c621bb494e7c2de871221638aa642126a805/test_path.py#L1142). [Until recently](https://github.com/python/cpython/commit/7ea9a85f132b32347fcbd2cbe1b553a2e9890b56), PDB used to look exclusively at $HOME and [the backport still does](https://github.com/jaraco/backports.pdb/blob/8fa8e80043a09103adac5b19cb29fe0cf5d0328c/backports/pdb.py#L164-L178). Devpi client [relies on setting home for tests](https://github.com/devpi/devpi/blob/7b2a40e87e9927a28eb554d0454130cd663e34f3/client/testing/test_use.py#L380). > we are facing a targeted exploit. What is the exploit? I don't think the downsides of honoring HOME on Windows were captured above. >From what I could tell, there was one (fairly obscure) case where HOME was set >unexpectedly. That hardly seems like a justification to reverse a >long-standing documented feature that aligns with the expectation of other >tools in the ecosystem. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36264> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
