Jason R. Coombs <jar...@jaraco.com> added the comment:
Today I ran into an issue due to this change. I have a test that sets `os.environ['HOME']` in order to ensure that `os.path.expanduser(~)` returns that value (https://github.com/pypa/setuptools/blob/f6f25adfc81df76e186bf6c3738a1baa0f92be05/setuptools/tests/test_packageindex.py#L288). > I can't find any documentation of `HOME` being relevant on windows (only on > posix). First, I'll nitpick that Windows is posix-compliant. What you probably mean here is "Unix". But the important thing here is that one of the beautiful things about Python is how it _bridges_ the gap between Unix and Windows, in many ways providing a uniform interface across various platforms. By supporting `HOME`, Python provides a single mechanism that a caller can rely on to indicate a home directory. With this change, a user is now required to provide separate guidance for invocation on Windows. In addition to the Setuptools test above that failed, I know I've relied on this behavior before in uses where I've written documentation advising users to set "HOME" to override a location derived from ~ (perhaps for .pypirc, but probably for others as well). Now guidance like that changes from: Set HOME to the target directory. to: If on Windows and Python 3.8 or later, set USERPROFILE to the target directory. Otherwise, set HOME to the target directory. It also means that code like the tests in Setuptools need to implement this branching logic as well. Can we restore _some_ mechanism by which a caller can supply the home directory in a unified way? ---------- nosy: +jaraco _______________________________________ 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
