An obstacle to centralizing code-generation routines (for use with
COG or otherwise) is the
python path. First of all, if you're not familiar with them, check out my previous post about
python packages.
The problem:
When running a statement like
import ADW, the Python interpreter looks for a file named "ADW.py", or a package
named "ADW" in the
sys.path. From the python
sys module docs:
- path
-
A list of strings that specifies the search path for modules.
Initialized from the environment variable PYTHONPATH, plus an
installation-dependent default.
As initialized upon program startup,
the first item of this list, path[0], is the directory
containing the script that was used to invoke the Python
interpreter. If the script directory is not available (e.g. if the
interpreter is invoked interactively or if the script is read from
standard input), path[0] is the empty string, which directs
Python to search modules in the current directory first. Notice
that the script directory is inserted before the entries
inserted as a result of PYTHONPATH.
A program is free to modify this list for its own purposes.
Changed in version 2.3:
Unicode strings are no longer ignored.
So, to have one group of python files used from different directories, we could manually append to
sys.path, to be sure that no matter what
project we work on, our set of python packages is in scope, but this gets very messy. We don't want to add
sys.path.append('C:\\Documents and Settings\\etc') to every project. Hard-coding absolute paths will complicate multiple people working on
the python modules.
The solution:
Python has a directory in its install root called
libs/site-packages. This directory is always in the
sys.path, and it is
intended as a place for third-party packages to be installed on a system.
SpamBayes installs
there, as well as a few others. Any packages in here are always importable. For more information check out the Python Enhancement Proposal (PEP)
describing
site-packages.
How we'll use it:
The desired configuration is to have the Visual Studio project containing all the python files reside in a
libs/site-packages subdirectory. That way, we can include that project in any other solution, and everything just works. To
accomplish that, get the python solution from source control to the
libs/site-packages dir. Since the project is stored a
directory lower than the solution, it works out the way we want.