Both. It depends on whether you are setting system-wide environment variables or user environment variables. But this differentiation is only made when storing environment variables that persist. When you set them in a “wrapper script” it’s only local to that session. As explained above that’s recommended as you won’t be “messing” with any administrator stuff of managing the local workstation.
For python to be recognized as a command in a command prompt it’s executable must be on the PATH (or in the running directory cwd)
Think of a computer being completely oblivious to whatever is stored on the hard-disk. It doesn’t know anything. You’ve Python in a specific folder stored somewhere, it doesn’t know! The only reason why an OS will know a command is because it’s told where it is to run it. Similar to PYTHONPATH you’d have to tell it where to look.
For example if Python is in C:\Python27 then add it to your PATH.
set PATH=%PATH%;C:\Python27
Now if you run python as a command the command prompt will look under the current working directory whether it finds it. If not it’s assuming you’re running a command that’s on your path. So it will go through all the paths under PATH until it finds a python executable in there. If it doesn’t find it, the computer will tell you the command doesn’t exist.
Actually, this is what the “wrapper scripts” could be doing. They are not actually “setting” the environment variables that you see when you go to “Computer” > “Advanced” > “Environment Variables” stuff, because we’re not setting them “on the system” but in the session of the wrapper script and then running the implementation.
For example try a .bat file like this:
set PYTHONPATH=%PYTHONPATH%;\\studio\DFS\Pipeline\pythonpath
set PATH=%PATH%;\\studio\DFS\Pipeline\path
call cmd
You’ll have an open command prompt now that has that environment variables set. In there you could start Python, run pyblish, etc. if it’s exposed in the paths set in this file.
Now instead of starting cmd at the end imagine running maya at the end. Basically the command prompt would close, but Maya would start to run (within that environment!) Voila! You’d have your first launcher script to launches Maya. A wrapper script if you will that does all of it for you where you don’t have to “manage” the system itself.
Even better, when updating the environment all you’d need to do is change the script.
it is related to be too?
Somewhat yes. be is a framework that allows you to manage environment that you enter and run an application within it. Again, you’re not setting the environment variables for the user and storing them on the system. You’d be entering the environment each time to launch the application. And that’s when you are running into “wrapper scripts” to ease entering the environment you want for that application.
Even though setting variables on the system itself and then “living with that” works just fine, it’s much harder to manage over time with many many systems. Unless again that whole “hardcoding” of the environment is done with a management system or set of scripts… but again, when going that far? Why not manage the environment on much lower-level, like whenever wrapping the environment?
Again, the recommendation here is to manage this with “wrapper” scripts so that you maintain control in a much more logical sense instead of managing all environment variables system-wide per machine that you have operating. Especially since you might want to change environments depending on the project you’re running, and that’s where the real power comes in.
