Environment Variables
In most operating systems there is the concept of environment variables. A common-ground for all applications on your computer, most of which will only read from it but some who also writes to it. You can think of it as a file on disk that everything accesses whenever the user stores a setting or an application requests one. In programming terms, it can be thought of as a singleton or global variable.So how does one access the environment? Well, it depends on your point of entry.
From the command line in Windows 7, you can go
>>> set // Print all environment variables PROCESSOR_LEVEL=6 PROCESSOR_REVISION=3a09 ProgramData=C:\ProgramData ProgramFiles=C:\Program Files ProgramFiles(x86)=C:\Program Files (x86) ... >>> set windir // Print a single variable windir=C:\Windows >>> set myVariable=MyValue // Create a new variable and print it >>> set myVariable myVariable=MyValue
And on Both Mac and Linux\Ubuntu using bash, you can go
>>> env // Print all environment variables XDG_CURRENT_DESKTOP=Unity LESSCLOSE=/usr/bin/lesspipe %s %s LC_TIME=en_GB.UTF-8 COLORTERM=gnome-terminal XAUTHORITY=/home/marcus/.Xauthority LC_NAME=en_GB.UTF-8 _=/usr/bin/env ... >>> printenv XDG_CURRENT_DESKTOP // Print a single variable Unity >>> export myVariable=MyValue // Create a new variable and print it >>> printenv myVariable MyValue
We, however, are mainly interested in accessing it via Python
>>> import os >>> for key, value in os.environ.iteritems(): >>> print "%s=%s" % (key, value) // Print all environment variables XDG_CURRENT_DESKTOP=Unity LESSCLOSE=/usr/bin/lesspipe %s %s LC_TIME=en_GB.UTF-8 COLORTERM=gnome-terminal XAUTHORITY=/home/marcus/.Xauthority LC_NAME=en_GB.UTF-8 _=/usr/bin/env ... >>> os.environ['MyVariable'] = MyValue // Create a new variable and print it >>> print os.environ['MyVariable'] MyValue
One variable you might already be familiar with is PATH. Which is, according to wiki.. "..a list of directory paths. When the user types a command without providing the full path, this list is checked if it contains a path that leads to the command." You usually store executables that you would like to run from a command line of sorts.
Another useful and common one is the PYTHONPATH. This is a variable which python looks for when determining which paths to use when searching for modules during import.
So, cmd.exe uses PATH to determine what executables are available and python uses PYTHONPATH. How about we make our own dependency? Couldn't we specify a CurrentProject variable that our library could use to determine which project we are in, in addition to Maya, Nuke, or any other program that might like to know about it? In this sense, CurrentProject is a global variable, accessible by everything that is run as a child of the OS.
Global is usually not the answer, however, but there is one thing that helps us with compartmentalization. Any time you open an application that needs the environment in any way, the environment is copied in to the running process. This means that modifying the environment from inside a child process is merely modifying it's own copy of the environment. It's own duplicate. You can think of this as a child process inheriting from its parent process.
This can be both a blessing and a curse. In some cases, it would be great to modify a variable and have all applications know about it so that they can update accordingly. But there are better ways around that. For instance, whenever a change occurs, a signal could be emitted to dependent processes to update accordingly. That way, not only can you control the flow of updates, but it also helps in keeping things tidy.
What's next
So, we'd like to modify our environment to store information about the context and then have Maya et al. make use of it. How do we go about doing this?The terminal
Via the terminal, you can read the file system, create and edit files, folders. You can also modify the environment. This, in addition to the fact that the terminal contains a full copy of all environment variables, means that we can edit the environment inside the terminal and then start an application from it. This would make the terminal a child of the OS, and the application a child of the terminal. The OS would maintain it's own original of the environment, the terminal would contain a modified version and then this modified version would get passed along to Maya (which, in turn, would then make another duplicate of this environment). In fact, we could launch several processes via the terminal and each one would get the same modified copy of the environment from the parent, our terminal.o Windows
o Terminal
o Maya
o Nuke
o Mari
Each level of this hierarchy is an opportunity to modify the environment, which means that we could separate modifications into groups related to the context in which it is getting modified. For example, the operating system could assign variables related to the overall operation of every application, independent of the user. The terminal then lets the user add to that via custom commands, such as setting the current project. Maya would then have a final copy with all of the information that it needs to operate.
But wait, there's more! In addition to these three levels of updating our environment, it can in fact happen at a few more levels.
o Boot
o Windows
o Login (per user)
o Launch Terminal (per terminal)
o Custom Commands
o Per Project
o Per Asset
o Maya
o Nuke
o Mari
As you can see, we can assign each of these level a responsibility and have a very dynamic way of interacting with our applications. Letting them know exactly what is going on with very little effort.
In the next part, I'll go through implementation and some of the problems I encountered along this path. Such as how to work around the fact that a process cannot edit it's parent environment.
