Flatpak CommandRunner Migration (Issue #20 Part 3)

Start by comparing the Flatpak package manager implementation with the established APT, YUM, and Snap CommandRunner patterns, then inspect the existing CommandRunner and MockCommandRunner interfaces. Done means Flatpak uses injected command execution, preserves existing behavior, adds the requested tests and documentation, and satisfies the listed acceptance criteria.

Summary

Migrate Flatpak package manager from direct exec.Command calls to unified CommandRunner interface for consistent, testable command execution architecture.

This is Part 3 of Issue #20 - CommandRunner Pattern Implementation

Background

Complete the CommandRunner migration initiative by implementing unified command execution patterns for Flatpak, achieving full architectural consistency across all package managers.

Current State

• APT: ✅ Uses CommandRunner (Issue #27 completed)
• YUM: ✅ Uses CommandRunner (already implemented)
• Snap: Direct exec.Command calls (Issue #28 - Part 2)
• Flatpak: Uses direct exec.Command calls

Scope

• Flatpak package manager migration from exec.Command to CommandRunner
• Constructor standardization following established APT/YUM/Snap patterns
• Dependency injection for comprehensive testing capabilities
• Test coverage expansion (currently 0% coverage for Flatpak)

Technical Implementation

CommandRunner Integration

• Replace all exec.Command calls with CommandRunner interface
• Implement automatic LC_ALL=C handling for consistent English output
• Add built-in interactive mode support via RunInteractive()
• Enable dependency injection for testing

Constructor Pattern

Following established standardization:

• NewPackageManager() - Production use with default CommandRunner
• NewPackageManagerWithCustomRunner() - Testing use with mock CommandRunner

Testing Infrastructure

• Implement comprehensive mock-based testing
• Add environment variable tracking capabilities
• Create cross-platform test scenarios
• Achieve significant test coverage improvement (currently 0%)

Benefits

Architecture Benefits

• ✅ Complete consistency - All package managers use same CommandRunner pattern
• ✅ Automatic LC_ALL=C - No manual environment setup needed
• ✅ Built-in interactive support - Proper stdin/stdout/stderr handling
• ✅ Unified codebase - Same patterns and interfaces everywhere

Testing Benefits

• ✅ Consistent testing - Same mocking approach across all package managers
• ✅ Environment testing - Built-in environment variable verification
• ✅ Cross-platform testing - Same tests work across all environments
• ✅ Full coverage - All command execution paths testable

Project Completion

• ✅ Issue #20 completion - All package managers migrated to CommandRunner
• ✅ Architectural consistency - Unified command execution across entire codebase
• ✅ Testing maturity - Comprehensive test coverage for all package managers

Acceptance Criteria

• Flatpak migrated from direct exec.Command to CommandRunner
• Constructor naming follows established patterns
• Dependency injection implemented for testing
• Comprehensive test coverage added (target: >80%)
• LC_ALL=C automatically handled
• Interactive mode works consistently
• All existing functionality preserved
• Documentation updated
• Issue #20 marked as complete

Priority

Medium Priority - Final piece of architectural consistency improvement.

Dependencies

• Should follow patterns established in Issue #27 (APT) and Issue #28 (Snap)
• Can be implemented in parallel with Issue #28 (Snap)

Related Issues

• Completes Issue #20 - CommandRunner Pattern Implementation
• Part of the same initiative as Issue #27 (APT) and Issue #28 (Snap)

Implementation Notes

• Follow proven patterns from APT migration (Issue #27)
• Leverage existing CommandRunner interface and MockCommandRunner
• Maintain backward compatibility during migration
• Use established testing frameworks and patterns
• This completes the full CommandRunner migration across all package managers