stoorps/aim
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

refactor: rename aim to upm and extract appimage module

Browse source
This commit is contained in:
stoorps 2026-03-21 22:39:11 +00:00
parent af13e98eb3
commit 863c57e473
Signed by: stoorps
SSH key fingerprint: SHA256:AZlPfu9hTu042EGtZElmDQoy+KvMOeShLDan/fYLoNI
117 changed files with 2622 additions and 887 deletions
Download patch file Download diff file Expand all files Collapse all files

31
.architecture/overview.md
View file

@ -2,20 +2,22 @@
## Workspace Shape
`aim` is a Rust workspace with two main crates:
`upm` is a Rust workspace with three main crates:
- `crates/aim-core`: source normalization, provider adapters, install/update planning, payload installation, registry persistence, and desktop integration.
- `crates/aim-cli`: argument parsing, config loading, terminal UX, prompting, progress reporting, and summary rendering.
- `crates/upm-core`: source normalization, add/update orchestration, registry persistence, install policies, desktop integration, and the provider-composition seam.
- `crates/upm`: argument parsing, config loading, terminal UX, prompting, progress reporting, summary rendering, and provider assembly.
- `crates/upm-appimage`: AppImageHub transport, search-provider behavior, and exact add-resolution for AppImage-backed installs.
The split keeps product logic in `aim-core` so additional frontends can reuse the same install and update pipeline.
The split keeps frontend-agnostic logic in `upm-core`, while concrete package-source behavior is composed at the CLI boundary. That keeps the headless layer reusable for future frontends without making provider behavior a permanent core dependency.
## Core Flow
The main execution path is:
1. Parse CLI input and load runtime config in `aim-cli`.
2. Resolve the query into a normalized source in `aim-core`.
3. Build an add or update plan through provider adapters and artifact selection.
1. Parse CLI input and load runtime config in `upm`.
2. Assemble a `ProviderRegistry` in `crates/upm/src/providers.rs`.
3. Resolve the query into a normalized source in `upm-core`.
4. Build an add or update plan through core orchestration plus any registered external providers.
4. Download the selected AppImage into a staged path.
5. Verify integrity metadata when available.
6. Commit the payload into the managed install location.
@ -33,7 +35,16 @@ Supported source classes currently include:
- direct URLs
- local file imports
Provider-specific resolution lives in `crates/aim-core/src/adapters` and `crates/aim-core/src/source`.
Core source normalization and orchestration live in `crates/upm-core`. AppImageHub-specific transport and provider behavior live in `crates/upm-appimage` and are injected through `ProviderRegistry` rather than hardcoded into core entrypoints.
## Runtime Interface
The rename to `upm` is a hard cutover:
- runtime overrides use `UPM_*`
- legacy `AIM_*` runtime overrides are not read
- default config, registry, payload, and desktop-entry paths use `upm` names
- helper audit logging uses `UPM_DEBUG_EXTERNAL_HELPERS=1`
## Security Hardening State
@ -51,9 +62,9 @@ The remaining deferred AppImageHub host-trust concern is tracked in `security-is
## Persistence And Integration
- Registry writes are atomic and live under the registry store implementation in `aim-core`.
- Registry writes are atomic and live under the registry store implementation in `upm-core`.
- Managed payload, desktop entry, and icon paths are resolved from install policy and scope.
- Desktop integration refresh uses external helpers when available and now supports env-gated audit logging through `AIM_DEBUG_EXTERNAL_HELPERS=1`.
- Desktop integration refresh uses external helpers when available and now supports env-gated audit logging through `UPM_DEBUG_EXTERNAL_HELPERS=1`.
## Planning And Audit Artifacts