make connections work with string annotations

[paul-nechifor]

Make connections work with string annotations. I.e. when from __future__ import annotations is used.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

[greptile-apps]

Greptile Overview

Greptile Summary

Adds support for PEP 563 string annotations by using get_type_hints() to resolve annotation strings to actual types. This allows modules using from __future__ import annotations to work correctly with the blueprint connection detection system.

• Modified _make_module_blueprint() to use get_type_hints() instead of directly accessing __annotations__
• Added test helper module with future annotations enabled
• Added comprehensive tests validating both blueprint creation and autoconnect functionality
• Removed unnecessary type ignore comments that were masking comparison overlap warnings

Note: The exception handling fallback may silently fail if get_type_hints() raises an exception in modules with future annotations, as raw string annotations won't be detected by get_origin().

Confidence Score: 3/5

• This PR is moderately safe to merge with one logical issue in error handling
• The main implementation correctly handles the happy path for future annotations, and comprehensive tests validate the functionality. However, there's a logical flaw in the fallback exception handler that would silently fail to detect connections if get_type_hints() raises an exception in modules using future annotations
• dimos/core/blueprints.py - review the exception handling fallback logic

Important Files Changed

File Analysis

Filename	Score	Overview
dimos/core/_test_future_annotations_helper.py	5/5	Added test helper module with future annotations to validate PEP 563 support
dimos/core/test_blueprints.py	5/5	Added comprehensive tests for future annotations support in blueprint creation and autoconnect
dimos/core/blueprints.py	3/5	Modified to use get_type_hints() for resolving string annotations, but fallback path silently fails with future annotations

Sequence Diagram

sequenceDiagram
    participant Client as Client Code
    participant Blueprint as _make_module_blueprint
    participant TypeHints as get_type_hints()
    participant Module as Module Class
    participant Annotations as __annotations__
    
    Client->>Blueprint: _make_module_blueprint(FutureModuleOut)
    Blueprint->>TypeHints: get_type_hints(module)
    TypeHints->>Module: access __module__ namespace
    TypeHints->>Module: resolve string "Out[FutureData]"
    Module-->>TypeHints: namespace with Out, FutureData
    TypeHints-->>Blueprint: {data: Out[FutureData]}
    
    alt get_type_hints succeeds
        Blueprint->>Blueprint: get_origin(Out[FutureData]) → Out
        Blueprint->>Blueprint: get_args(Out[FutureData]) → (FutureData,)
        Blueprint->>Blueprint: create ModuleConnection
    else get_type_hints fails
        Blueprint->>Annotations: fallback to __annotations__
        Annotations-->>Blueprint: {data: "Out[FutureData]"}
        Blueprint->>Blueprint: get_origin("Out[FutureData]") → None
        Note over Blueprint: Connection NOT detected (bug)
    end
    
    Blueprint-->>Client: ModuleBlueprint with connections

Loading

[greptile-apps]

_{3 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

logic: fallback code silently breaks with future annotations - when get_type_hints() fails, raw __annotations__ are strings due to PEP 563, so get_origin() returns None and connections aren't detected. Consider catching specific exceptions like (NameError, AttributeError, TypeError) similar to module.py:296, or building proper globalns like module.py:289-292