Class based approach#7
Draft
davidkopp wants to merge 2 commits into
Draft
Conversation
- Add new DependencyResolver class for advanced programmatic usage - Implement parallel processing for multiple environments using ThreadPoolExecutor - Add ResolveRequest and ResolveResult dataclasses for structured configuration - Support progress tracking via optional callback functions - Refactor venv_path from resolver-level to per-request configuration - Add comprehensive test suite with 16 test cases covering all functionality - Update README with detailed usage examples for all three interfaces: - Functional interface for simple operations - Class-based interface for parallel processing - Low-level interface for advanced control - Maintain full backward compatibility with existing functional API Key features: - Batch resolution with configurable parallelism (max_workers) - Per-request configuration (venv_path, working_dir, environment settings) - Error handling with detailed result objects including execution time - Multiple output formats (list of results, consolidated dictionary) - Progress monitoring for long-running batch operations 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Move environment_type and only_container_info from per-request to per-class model while keeping environment_identifier per-request for flexibility: - Environment type and container-specific options configured in DependencyResolver constructor - Environment identifier passed per-request to enable batch processing of multiple containers/services - ResolveRequest simplified to contain identifier, working directory, and detector options - Added validation that only_container_info only works with docker environment - Updated all usage sites including CLI, convenience functions, and tests - Updated README.md documentation with better examples showing batch processing This design correctly separates configuration concerns (per-class) from data concerns (per-request), enabling efficient analysis of multiple containers with the same resolver instance. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ich bin mir nicht sicher, wie die programmatische Schnittstelle (Python API) vom dependency-resolver am besten aussehen soll. Diese ist ja letztlich relevant für die Integration in GMT.
Bislang gibt es eine Funktions-basierte Schnittstelle. Ich habe Claude gebeten mal eine Klasse-basierte Schnittstelle zu erstellen. Ich finde eine Klasse zu haben irgendwie schöner, jedoch erscheint mir das jetzt doch zu over-engineered zu sein. Deshalb hier mal nur als Draft.
Claude meinte, dass die Funktionsbasierte Variante ausreichend ist, jedoch die Klassen-basierte Variante dann einen Mehrwert bringt, wenn die parallele Ausführung mehrerer Resolving-Aktivitäten eine Anforderung ist.
Parallelität ist für die GMT-Anforderung denke ich eine relevante Anforderung, jedoch könnte das auch GMT übernehmen.
Vergleich der Schnittstellen
Funktions-basiert
Klassen-basiert
Simpel
Parallelität