Metadata-Version: 2.4
Name: dcm-processor
Version: 2.0.0
Summary: A Command line tool for the dicom processor library
Home-page: https://github.com/giesekow/dcm-processor-cli
Author: Giles Tetteh
Author-email: giles.tetteh@tum.de
Keywords: orthanc,dicom,worker,processor,translation,medical
Classifier: Programming Language :: Python :: 3
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Description-Content-Type: text/markdown
License-File: LICENSE
Requires-Dist: dcm-processor-db-provider==0.0.1
Requires-Dist: dcm-processor-dicom-server==0.0.1
Requires-Dist: dcm-processor-job-scheduler==0.0.1
Requires-Dist: dcm-processor-utils==0.0.1
Requires-Dist: dcm-processor-worker==0.0.1
Requires-Dist: mqas
Requires-Dist: psutil
Requires-Dist: requests==2.32.4
Requires-Dist: tabulate==0.10.0
Requires-Dist: tomlkit==0.14.0
Dynamic: license-file

# dcm-processor-cli

`dcm-processor-cli` is the main user-facing entry point for the dcm-processor platform.

It is the control-plane package that developers, operators, and maintainers use to:

- create and initialize applications
- install and uninstall services and workers
- configure DICOM nodes, peers, services, workers, and app settings
- start, stop, restart, and inspect application runtimes
- authenticate against the package registry and publish packages

## Role In The Bigger Picture

If the overall platform is viewed as a processing system, this module is the front door.

It does not ingest DICOM data itself and it does not execute processing code directly. Instead, it coordinates the other modules:

- `dcm-processor-db-provider` for persistence and configuration storage
- `dcm-processor-worker` for worker installation and execution
- `dcm-processor-dicom-server` for DICOM ingestion
- `dcm-processor-job-scheduler` for job orchestration
- `dcm-processor-utils` for shared helper logic

When an application is started through the CLI, the runtime stack is assembled through those lower-level modules.

## Main Responsibilities

### 1. Application Lifecycle

The CLI creates, initializes, starts, stops, restarts, backs up, restores, and inspects applications.

Key commands:

- `dcm-processor create`
- `dcm-processor init`
- `dcm-processor start`
- `dcm-processor stop`
- `dcm-processor restart`
- `dcm-processor status`
- `dcm-processor logs`
- `dcm-processor backup`
- `dcm-processor restore`

These commands are the operational entry point for the full application stack.

### 2. Package Installation

The CLI installs packages from:

- local directories
- local archives
- direct web URLs
- the dcm-processor registry

It understands package manifests through `dcm-processor.json` and installs:

- service code
- worker definitions
- dependent services and workers when required

### 3. Configuration Management

The CLI exposes management commands for:

- DICOM nodes
- DICOM peers
- services
- workers
- application settings

This makes it the operational shell around the stored application model.

### 4. Registry Access

The CLI is also the registry client.

It supports:

- login
- logout
- publish
- package install from registry queries like `name`, `name==1.2.0`, `name>=1.2.0`

## Key Internal Areas

- `dcm_processor/manager.py`
  - main CLI parser and command dispatch
- `dcm_processor/app_manager.py`
  - application lifecycle and backup/restore workflows
- `dcm_processor/registry_manager.py`
  - registry login, logout, and publish
- `dcm_processor/install_manager.py`
  - install and uninstall command entry points
- `dcm_processor/libs/component_lib.py`
  - service and worker install orchestration
- `dcm_processor/libs/app_runner.py`
  - runtime assembly for app start/stop

## Typical Flow

1. A user creates or initializes an application.
2. The CLI stores and reads app configuration through `dcm-processor-db-provider`.
3. The CLI installs services and workers from package artifacts.
4. The CLI starts the runtime stack.
5. The runtime stack then runs through the scheduler, worker, and DICOM server modules.

## What This Module Is Not

This package is not:

- the database abstraction layer
- the DICOM listener
- the scheduler itself
- the worker execution engine
- the service SDK used inside processing code

It coordinates those pieces, but it is not their implementation.

## Summary

Use this module when you need to interact with the dcm-processor platform as a system:

- install things
- configure things
- run things
- publish things

It is the main operational interface for the rest of the modules.
