利用者:NBurn/Setting up Python Debugger with Blender

Rough Draft

---

General overview of remote debugging:

If you are not familiar with remote debugging, the general idea is you want your debugger and your "remote" application (Blender in this case) to be accessing the same code at the same time with the debugger acting as a "code guide", determining when each piece of code is executed.

The actual debugging process looks something like this:

• First the code is loaded into the debugger
• Next the debugging server is started
• Then the "remote" application is launched and it runs the exact same code the server is hosting
• Finally (if there's no problems) the "remote" application should pause at the breakpoint and wait for the debug server to continue the code execution

Note that "remote application" does not necessarily mean a program running on a different computer, it can be another application on the same computer as the debug server.

To tell Blender to use a remote debugger, edit the Python code it will be running so it contains a link to the Python debugger the server uses at the beginning of the code, followed by a "breakpoint" where the code execution will be paused.

---

Eclipse debugging workflow (after setup is finished):

1. Load code you want to debug in Eclipse
2. Launch the Pydev debug server in Eclipse (Pydev > Start Debug Server)
3. Open Blender
4. Open the same code from the debugger in Blender's Text Editor
5. Run the code you just opened in Blender's Text Editor (Run Script)
6. Wait for the Eclipse debug server to connect to Blender
7. Debug...

---

PyCharm debugging workflow (after setup is finished):

1. Load code you want to debug in PyCharm
2. Launch PyCharm's debug server (Waiting for process connection...)
3. Open Blender
4. Open the same code from the debugger in Blender's Text Editor
5. Launch Blender debugger addon (Connect to remote PyCharm debugger)
6. Wait for PyCharm debugger to attach to Blender (Connected to pydev debugger)
7. Run code you want to debug from Blender's Text Editor (Run Script)
8. Debug...

still feels like a step or two is missing...

need to figure out proper setup so there's no "file.py can't be found in project" error

etc

---

Overriding VIEW_3D

Code for overriding addon defined operators that are 3D View (view3d) dependent. This may be useful as a workaround for code that would otherwise fail when launched from outside the 3D View (like code being debugged that was rewritten to launch from Blender's Text Editor):

def AssembleOverrideContextForView3dOps():
### IMPROVE: Find way to avoid doing four levels of traversals at
# every request!!
    for oWindow in bpy.context.window_manager.windows:
    # Iterates through the Blender GUI's windows, screens, areas, and regions
    # to find the View3D space and its associated window.  Populates an
    # 'oContextOverride context' that can be used with a bpy.ops  operator
    # that would normally need to be used from within a View3D context (like
    # most addon code that runs off of View3D panels).
    # Tip: If your operator fails, the log will show an
    # "PyContext: 'xyz' not found" error. To fix, stuff 'xyz' into the
    # override context and try again!
        oScreen = oWindow.screen
        for oArea in oScreen.areas:
            if oArea.type == 'VIEW_3D':
            ###LEARN: Frequently, bpy.ops operators are called from View3d's
            # toolbox or property panel.  By finding that window/screen/area
            # we can fool operators in thinking they were called from
            # the View3D!
                for oRegion in oArea.regions:
                    ###LEARN: View3D has several 'windows' like 'HEADER'
                    # and 'WINDOW'.  Most bpy.ops require 'WINDOW'
                    if oRegion.type == 'WINDOW':
                    #=== Now that we've (finally!) found the damn View3D,
                    # stuff all that into a dictionary bpy.ops operators can
                    # accept to specify their context.  I stuffed extra info
                    # in there like selected objects, active objects, etc as
                    # most operators require them.  (If anything is missing
                    # operator will fail and log a 'PyContext: error on the
                    # log with what is missing in context override) ===
                        oContextOverride = {'window': oWindow, \
                        'screen': oScreen, 'area': oArea, 'region': oRegion, \
                        'scene': bpy.context.scene, \
                        'edit_object': bpy.context.edit_object, \
                        'active_object': bpy.context.active_object, \
                        'selected_objects': bpy.context.selected_objects, \
                        'blend_data': bpy.data}   
                        # Stuff the override context with very common requests
                        # by operators.  MORE COULD BE NEEDED!
                        print("-AssembleOverrideContextForView3dOps() " + \
                        "created override context: ", oContextOverride)
                        return oContextOverride
    raise Exception("ERROR: AssembleOverrideContextForView3dOps() could " + \
    "not find a VIEW_3D with WINDOW region to create override context to " + \
    "enable View3D operators.  Operator cannot function.")

# Example usage
oContextOverride = AssembleOverrideContextForView3dOps()
bpy.ops.view3d.my_addon_idname(oContextOverride, 'INVOKE_DEFAULT')

The code is a slightly modified version of the example in this thread:
https://www.blender.org/forum/viewtopic.php?t=27834

---

Todo:

• Add more info on PyCharm and Eclipse / PyDev setup
• Add Visual Studio / PTVS debug setup
• Add specific setup details for the big 3 (Linux / Mac / Windows)
• More cleanup on "Overriding view3d" code sample