Across all operating systems, the environment is something that’s set up on a process by process basis; when a process spawns, it gets a copy of the environment of it’s parent, and that environment then becomes distinct (due to it being a copy). This is an important distinction because otherwise a process modifying its environment could conceivably break other software by changing something that it relies on.
If you notice that the environment (in your case the PATH) is different between two different processes, the reason for that is related to one of two things:
-
The environment in one process was modified after the second one was started; since they’re not connected at all, only the one with the modification sees the change.
-
The way a parent process sets the environment as it spawns the child can change depending on things like the OS and circumstance. For example:
-
Your shell (e.g. bash) sources different rc files to set itself up depending on how you invoke it; this is shell specific. For example if the shell is spawned as a normal shell instead of a login shell, or if it’s not interactive (or if it is).
-
On MacOS, programs that are started from the dock explicitly get a different environment set than you see in the terminal because the launch daemon doesn’t read any shell configuration files; that makes sure that no matter how you set your shell rc files, applications always work the same for everyone.
-
On Linux, the window manager that you’re using is the parent of any application that you start via it’s menus, dock items, etc. So whatever the window manager thinks the environment is, that’s what your child process gets. The environment is set by the parent and remains, so changing the environment without restarting the window manager results in the window manager maintaining the same environment until you restart it.
Based on your description, my guess would be that last one there, except that you mentioned Windows, in which case restarting Sublime should have updated the path for you.
Certainly if you install software that modifies the PATH, anything that’s already running is not going to see the PATH modification (or any other environment modification) until you restart it.
If you’re on Linux and you install something and then modify the PATH, running applications won’t see the path, but when you open a Terminal, it sources your rc files and gets the PATH you expect. However the Window Manager is still running with the original environment, and continues to do so.
Thus restarting Sublime has no effect because it’s still inheriting the same environment the window manager had the first time, but restarting the computer restarts the window manager, which picks up the brand new environment, and everything works as expected.
On Windows, just restarting a process is enough (so far as I have ever seen) for it to pick up the new environment.
On MacOS, Sublime starts a shell in the background to collect the environment to get around the issue of MacOS always using a constrained environment, so that build systems and the like will work as expected on that platform.
For full completeness here (as if this wasn’t long enough already), os.environ is part of Python and Sublime just accesses it as any Python program would.
As documented in the link above, it represents the environment at the time the module was first imported unless modifications are made to it directly, which tracks with the notion mentioned above that all processes have a separate environment.
