Modular Architecture

Architecture Overview

TinyPM is intentionally modular. The codebase is organized so that distro maintainers and downstream forks can keep the same user-facing interface while replacing or extending the internals.

Directory Structure

• atiny - main entrypoint script (also symlinked as tinypm, ainstall, etc.)
• tinypm-app - interactive terminal app
• version - fastfetch-style version output
• _spinner - spinner animation utility
• lib/core/ - core logic modules
• lib/providers/ - backend-specific provider logic
• share/ - catalog data and logo assets

Core Modules (`lib/core/`)

The core directory contains the central logic:

• Parsing - command-line argument parsing and flag handling
• App flow - routing commands to the right action
• Actions - the actual install/search/remove/list/run logic
• State - managed package tracking
• UI - terminal output formatting and colors
• Doctor - system diagnostic output

Providers (`lib/providers/`)

Each backend has its own provider module:

• Flatpak provider - wraps flatpak CLI commands
• Snap provider - wraps snap CLI commands
• APT provider - wraps apt CLI commands

Providers are loaded dynamically based on the backend flag or default selection logic. Each provider implements a consistent interface so the core does not need to know the specifics of each backend.

Shared Assets (`share/`)

The share/ directory contains:

• Discover catalog - the small curated app list for tinypm discover
• Logo assets - branding and terminal art

Why Modular?

This structure makes it easy to:

• Add new backends (e.g. pacman for Arch Linux / Abora)
• Replace providers for different distros
• Customize the discover catalog
• Fork and remix without touching core logic