Feature Request: Refactor Configuration Architecture for Better CLI/Library Separation

[rahlk]

Summary

Refactor the current parameter-passing approach to use a layered configuration pattern that cleanly separates CLI concerns from core analysis configuration, improving both library usability and maintainability.

Current State

The Codeanalyzer class currently accepts individual parameters in its constructor:

with Codeanalyzer(
    input, analysis_level, using_codeql, rebuild_analysis, cache_dir, clear_cache
) as analyzer:

This approach has several limitations:

• Library users must pass CLI-specific parameters (like clear_cache)
• Parameter explosion as new options are added
• Tight coupling between CLI and core analysis logic
• Hard to test - requires mocking many individual parameters
• No validation of parameter combinations
• No config file support - difficult to extend

Proposed Solution

1. Core Configuration Object

Create an AnalysisOptions class that contains only analysis-relevant settings:

@dataclass
class AnalysisOptions:
    input_path: Path
    analysis_level: int = 1
    using_codeql: bool = False
    rebuild_analysis: bool = False
    cache_dir: Optional[Path] = None
    
    def validate(self):
        # Centralized validation logic
        pass
    
    @classmethod
    def from_dict(cls, config: dict):
        # Support for config files
        pass

2. CLI Configuration Layer

Create a CLIOptions class for CLI-specific concerns:

@dataclass
class CLIOptions:
    output_dir: Optional[Path] = None
    output_format: OutputFormat = OutputFormat.JSON
    verbosity: int = 0
    clear_cache: bool = True
    
    def setup_logging(self):
        # Handle CLI-specific setup
        pass

3. Updated Core Interface

Modify Codeanalyzer to accept the configuration object:

class Codeanalyzer:
    def __init__(self, options: AnalysisOptions):
        self.options = options
        # Clean, single source of configuration

Benefits

For Library Users

• Clean API: Single configuration object instead of many parameters
• Type Safety: Better IDE support and validation
• Extensibility: Easy to add new options without breaking existing code
• Testability: Simple to create test configurations

# Clean library usage
options = AnalysisOptions(
    input_path=Path("my_project"),
    analysis_level=2,
    using_codeql=True
)
with Codeanalyzer(options) as analyzer:
    results = analyzer.analyze()

For CLI Users

• No breaking changes: CLI interface remains the same
• Better error messages: Centralized validation
• Future extensibility: Config file support, presets, etc.

For Maintainers

• Separation of concerns: CLI logic separate from analysis logic
• Easier testing: Mock configuration objects instead of individual parameters
• Better validation: Centralized parameter validation and type checking
• Extensibility: Easy to add features like config files, environment variables

Backward Compatibility

• CLI interface remains unchanged
• Library interface change is breaking, but provides clear migration path
• Consider deprecation warnings for old constructor signature

Testing Strategy

• Unit tests for configuration validation
• Integration tests for CLI/library interfaces
• Test configuration serialization/deserialization
• Test error handling and validation

Success Metrics

• Reduced coupling between CLI and core analysis
• Improved library API usability
• Foundation for future configuration enhancements
• Better test coverage of configuration logic

References

Similar patterns used successfully in:

• MyPy (mypy.options.Options)
• Black (black.FileMode)
• Pylint (pylint.config.Configuration)
• WALA (AnalysisOptions)