自动修补 PYTHONPATH（使用 Fabric 任务时）

Question

I wrap function calls within my initialization module with a decorator that patches PYTHONPATH to add current directory to it so I can use relative imports within my modules without worrying about adding the package to PYTHONPATH explicitly (edited based on @abarnert's comments)

def patch_python_path(f):
    @wraps(f)       
    def wrap(*args, **kwargs):
        ROOT = os.pathsep.join([os.path.abspath(os.path.dirname(__file__))])
        if not os.environ.has_key("PYTHONPATH"):
            os.environ["PYTHONPATH"] = ""
        if not (ROOT in os.environ["PYTHONPATH"].split(":")):
            os.environ["PYTHONPATH"] = "%s:%s" % (os.environ["PYTHONPATH"], ROOT)
        if not ROOT in sys.path:
            sys.path.append(ROOT)
        return f(*args, **kwargs)
    return wrap

Here's how I use it:

@patch_python_path
def initialize():
    #at this point any code being run has access to local modules through relative imports
    pass

Are there any major issues with this approach that I am not aware of?

---

My objectives with this are the following:

• i want to have a self contained bootstrap that a user can immediately use without any additional env manipulations
• i also assume that a user can change the name of the bootstrap package so it's imperative that all the imports remain relative

[EDIT] I'm actually realizing that the problem I am facing has more to do with the way Fabric runs tasks as opposed to pure Python module importing. If I attempt to run a task from a python shell (as opposed to fab task1) all the imports are resolved correctly without any patching required. Running a task through fab causes import errors

Answer 1

1. os.environ is global. You're modifying it, and not modifying it back afterward. So, after doing @patch_python_path on any function, you've now done the equivalent for everything else you define after that—including in other modules and in the top-level script.
2. sys.path is also global, and again you're modifying it and not restoring it.
3. You shouldn't ever need to modify both PYTHONPATH and sys.path . (In particular, it's the former that you usually shouldn't need.)
4. You're adding . to PYTHONPATH , but os.getcwd() to sys.path . If you ever do need to modify both, everything will stop working after an os.chdir() , which will effectively change the PYTHONPATH but not the sys.path .
5. Any wrapped function will lose its docstring, name, etc.; use @functools.wraps on your wrap function.

Those are all just issues with your implementation, without getting into whether it's a good idea in the first place.

The most common reasons people want something like this are (a) make Python XY packages work like Python VW, and (b) allow importing a package from the source tree to work the same as importing it after install, even from the interpreter shell. The former is probably a bad idea; the latter is handy, but there are other ways to accomplish it. If you have some different higher-level goal, you'll have to tell us what that goal is before anyone can tell you whether this is the best way to accomplish it.

Answer 2

You might simply add current path to sys.path :

import sys
def patch_python_path(f):
    def wrap(*args, **kwargs):
        if not '.' in sys.path:
            sys.path.append('.')
        return f(*args, **kwargs)

    return wrap