Based on the structure and content of the data you provided, this is a listing of **platform-specific binary wheels (.whl files)** for the Python package charset_normalizer version 3.4.9.

In simple terms, it's an index showing every possible combination of operating system (OS) and CPU architecture that can run this specific piece of software.

Here is a detailed breakdown of what this data means and why there are so many different files:

***

### 💡 Core Concept: Why So Many Files?

When a Python package contains compiled code (meaning it has parts written in C, C++, or other low-level languages that need to interact directly with the operating system kernel), it cannot be universal. The way that compiled code interacts with the OS and CPU is unique for every platform.

*   **Example:** Code compiled for an Intel/AMD 64-bit processor (`x86_64`) will not run on a Raspberry Pi running ARM architecture (`armv7l`), even if they are both running Python.
*   **The Solution:** Package managers (like `pip`) must download the exact wheel file that matches your specific combination of OS and CPU to ensure the package installs correctly and runs without errors.

### 📂 Breakdown by Category

The entries can be grouped into three main categories:

#### 1. Operating System / Environment
These prefixes tell you what kind of operating system or environment the compiled code is designed for:

*   **`manylinux...`**: These wheels are built to run on a wide variety of Linux distributions (like Ubuntu, Fedora, etc.). They represent standard compatibility targets.
    *   `manylinux_2_17_x86_64`: Standard 64-bit Intel/AMD Linux build.
    *   `manylinux_2_39_riscv64`: Build for RISC-V architecture on Linux.
*   **`musllinux...`**: These wheels are built specifically for environments that use the **Musl C library**, which is a lightweight alternative to the standard GNU C Library (glibc). This is common in containerized or minimal embedded Linux systems.
*   **`win32` / `win_amd64`**: Wheels designed for Microsoft Windows operating system (32-bit and 64-bit, respectively).

#### 2. Architecture (The CPU Type)
This part of the filename specifies the type of processor the code is compiled to run on:

*   **`x86_64`**: The standard architecture for modern desktop computers (Intel/AMD 64-bit).
*   **`aarch64`**: The 64-bit architecture commonly used by Apple Silicon Macs and many modern ARM servers.
*   **`armv7l`**: The 32-bit ARM architecture (common in older or smaller embedded devices).
*   **`s390x`**: Architecture specific to IBM mainframes/servers.
*   **`riscv64`**: Build for the RISC-V instruction set, a growing open-source CPU standard.

#### 3. Metadata (The Technical Details)
The rest of the data provides technical information used by package managers:

*   **`charset_normalizer-3.4.9`**: The name and version of the package.
*   **`hash = "sha256:..."`**: A cryptographic hash that verifies the file hasn't been corrupted or tampered with during download.
*   **`size = ...`**: The size of the wheel file in bytes.
*   **`upload-time = "..."`**: When this specific package version was uploaded to PyPI (the Python Package Index).

***

### 🎯 Summary for a Developer

If you were running your code on an **Apple Silicon Mac**, `pip` would ignore all the other entries and select the wheel matching:
*   **OS:** Linux/macOS compatible (`manylinux` or similar)
*   **Architecture:** `aarch64` (or sometimes a specific macOS wheel if available).

If you were running your code on an **old Windows XP machine**, it would select the `win32` wheel.
This commit is contained in:
2026-07-23 13:41:41 +02:00
commit 1ae576bd07
11 changed files with 722 additions and 0 deletions
+76
View File
@@ -0,0 +1,76 @@
# Immich external library to albums
This script creates Immich albums from the directory names in an external
library and adds the corresponding assets to them. It does not move or modify
the original files.
For example, with:
```text
EXTERNAL_ROOT=/mnt/nextcloud-photos
ALBUM_MODE=root
```
the asset:
```text
/mnt/nextcloud-photos/Korea_2016_07_08/photo.jpg
```
is added to an album named `Korea_2016_07_08`. Files in nested directories
below `Korea_2016_07_08` are added to the same album.
## Configuration
Required environment variables:
- `IMMICH_URL`: Immich server URL, for example `http://immich-server:2283`
- `IMMICH_API_KEY`: API key with `asset.read`, `album.read`,
`album.create`, and `albumAsset.create` permissions
- `IMMICH_LIBRARY_ID`: ID of the external Immich library
Optional environment variables:
- `EXTERNAL_ROOT`: Path stored in Immich's `originalPath`; defaults to
`/mnt/nextcloud-photos`
- `ALBUM_MODE`: `root` (default), `leaf`, or `relative`
- `ALBUM_SEPARATOR`: Separator for `relative` mode; defaults to ` - `
- `PAGE_SIZE`: Immich search page size; defaults to `1000`
- `DRY_RUN`: Set to `true` to log planned work without changing albums
Run the script after Immich has scanned the external library:
```bash
uv run python src/main.py
```
## Docker Compose
Copy the example configuration and insert your Immich API key and external
library ID:
```bash
cp .env.example .env
docker compose up --build
```
The example starts with `DRY_RUN=true`. Check the output, then set
`DRY_RUN=false` in `.env` and run `docker compose up` again.
When Immich publishes port `2283` on the same Docker host, use:
```text
IMMICH_URL=http://host.docker.internal:2283
```
For an Immich server on another machine, use its normal HTTP(S) URL instead.
The photo directory does not need to be mounted into this container:
`EXTERNAL_ROOT` is matched against the path recorded in Immich's
`originalPath` field.
The Compose service performs one synchronization and then exits. Run it after
an external-library scan, or invoke it regularly with a scheduler such as
cron.
The script only adds missing assets. It never removes assets from albums and
never deletes albums.