Add Missing TODO: Extract Global Variables in Dependency Resolution

[jeremymanning]

Overview

The dependency resolution system has a TODO marker indicating missing functionality for extracting global variables.

Current Status

Location: clustrix/dependency_resolution.py:359

Current Code:

global_variables={},  # TODO: Extract global variables

Problem Description

The dependency resolution system is not currently extracting and preserving global variables that functions may depend on. This could cause runtime errors when functions are executed remotely and expect certain global variables to be available.

Impact

• Functions that reference global variables may fail during remote execution
• Missing global context could lead to NameError exceptions
• Incomplete dependency analysis for complex functions

Implementation Requirements

1. Global Variable Detection

• Analyze function code to identify global variable references
• Distinguish between built-in globals and user-defined globals
• Handle nested function scopes appropriately

2. Global Variable Extraction

• Extract values of referenced global variables
• Handle serializable and non-serializable globals appropriately
• Provide fallback mechanisms for complex global objects

3. Remote Global Setup

• Reconstruct global variable environment on remote systems
• Handle global variable conflicts and namespacing
• Ensure proper global variable lifecycle management

Technical Considerations

AST Analysis for Global References

import ast

def extract_global_references(func):
    """Extract global variable references from function AST."""
    source = inspect.getsource(func)
    tree = ast.parse(source)
    # Analyze for global name references
    # Return list of global variable names

Global Variable Serialization

• Need to handle different types of global objects
• Consider circular references in global variables
• Handle module-level imports and functions

Testing Requirements

• Test functions with global variable dependencies
• Test nested global variable references
• Test global variable serialization/deserialization
• Test conflict resolution for global variables
• Test performance impact of global variable extraction

Related Components

• clustrix/dependency_resolution.py - Main implementation location
• clustrix/utils.py - Function serialization utilities
• clustrix/executor.py - Remote execution environment setup

Acceptance Criteria

• TODO comment is resolved with actual implementation
• Global variables are correctly identified for functions
• Global variables are properly serialized and transferred
• Remote execution environment includes necessary globals
• All existing functionality continues to work
• Comprehensive test coverage for global variable handling

Priority: Medium
Complexity: Medium-High

Source: Content found during codebase TODO/FIXME scan in Issue #74 content preservation automation.

[jeremymanning]

Verified still accurate (audit 2026-08-17). The TODO is present verbatim on origin/master:

clustrix/dependency_resolution.py:359 — global_variables={}, # TODO: Extract global variables

No change needed to this issue. Noting the verification so it is not re-audited.

Related: #90 covers the sibling gap in function_flattening.py (closure variables). These two are the remaining holes in the dependency-capture story and should probably be fixed and tested together — a function that references both a global and a closure variable is the case that exercises both paths.

[jeremymanning]

Obsolete — the module is deleted and the capability works

This asked to complete a TODO for global-variable extraction in clustrix/dependency_resolution.py.

$ ls clustrix/dependency_resolution.py
No such file or directory
$ grep -rn "TODO\|FIXME" clustrix/ --include=*.py | wc -l
0

The module was deleted in 0e3490e (PR #139) along with the flattening machinery it served. There is no TODO left anywhere in the package.

Module-global capture is not missing — it is verified working against real hardware. From docs/evidence/usecase-matrix.txt:89, generated by scripts/verify_cluster_usecases.py on a real SLURM node:

case module_global    expected 77    actual 77

Nothing to extract; the behaviour the TODO was for is already correct by a different route.