PR: Fix issue where user environment variables with line endings were not parsed correctly on Unix platforms

[mrclary]

Description of Changes

#20297 unsatisfactorily fixed #20097 by skipping environment variables that do not parse correctly. This PR remedies this.

• For unix, use a clean subprocess environment, invoke a login shell, extract os.environ from a python process. This circumvents any parsing issues and should reflect exactly what a user would expect from a python process in a standard terminal.
• For Windows, get environment variables directly from the system registry.
• Add regression test for ValueError when trying to get environment variables on Linux #20097
  • Modify user environment variables in system registry or shell startup file
  • Restore user environment variables
  • Only run on CI to protect developers' local user environment variables

Issue(s) Resolved

Fixes #20637.
Fixes #20242.
See #20097

[ccordoba12]

Thanks @mrclary for your work on this! Looks good to me, but I think it'd be nice if you could add a test for issue #20097, so we don't introduce a regression for it in the future.

[mrclary]

@ccordoba12, this might be a good time to review what the get_user_environment_variables function should actually do.

Perhaps we need to define, for the purposes of Spyder, what "user environment variables" means. I have a working definition which is:

• The exported environment variables present when a user starts a login shell.

For Windows users, this is very straight-forward: everything inherits from the registry, so these values can be collected directly from there.

For unix platforms, this is more complicated: it depends on the default shell and the profile startup scripts (e.g. /etc/bashrc, ~/.bash_profile, etc.). Ostensibly, os.environ has the "user environment variables", but it has additional variables used by Spyder, so cannot be relied on to be equivalent to "user environment variables". Additionally, the "user environment variables" in os.environ are set at Spyder launch, so Spyder would have to be restarted if these variables change.

For these reasons, I was motivated to use a subprocess to get the "user environment variables" rather than os.environ. However, there is an oversight here because the subprocess actually injects os.environ into the environment variables by default, so at present it does not achieve its intended goal. I was curious how the unit test for the pythonpath manager plugin worked when assigning os.environ['PYTHONPATH']; this is how I realized the oversight.

[ccordoba12]

Great work here @mrclary! I left some small suggestions for you, otherwise looks almost ready to me.

[ccordoba12]

Looks good to me now, thanks @mrclary!