LPM — Pakete anlegen und in die Registry einreichen

LPM ist der Lyx Package Manager. Er löst Abhängigkeiten auf, baut .lxpkg-Archive und kommuniziert mit der zentralen Registry unter lpm.seolizer.de.

Ein Lyx-Projekt beschreibt sich selbst in einer einzigen Datei: lyx.toml. Darin steht der Paketname, die Version, die Abhängigkeiten — und optional der Einstiegspunkt für den Compiler. LPM liest diese Datei und weiß damit alles was es braucht: welche Pakete geladen werden müssen, wie das Archiv heißt und wohin es hochgeladen wird.

Die Registry speichert jedes Paket versioniert und unveränderlich. Wer ein Paket unter [email protected] einreicht, kann diese Version nicht nachträglich ändern — das schützt alle, die diese Version als Abhängigkeit deklariert haben. Neue Versionen werden immer als eigener Eintrag veröffentlicht.

Was LPM kann:

LPM arbeitet direkt mit lyxc zusammen: nach lpm install gibt lpm resolve dem Compiler die -I-Pfade zu den heruntergeladenen Paketen — der eigene Code muss nichts weiter tun als import andreas.stringutils.trim; zu schreiben.

→ Tools-Übersicht · Compiler-Parameter · Erste Schritte

---

Config einmalig anlegen (~/.lpm/config.yml):

registry: https://lpm.seolizer.de
api_key: <dein-token>

Den Token vergibt der Server-Admin:

php admin.php add-token <dein-name>

---

mkdir mein.paket && cd mein.paket
lpm init --name mein.paket

lpm init erzeugt eine lyx.toml mit Pflichtfeldern. Fehlende Felder ergänzen:

[package]
name        = "mein.paket"
version     = "0.1.0"
author      = "Andreas Röne"
license     = "MIT"
description = "Kurze Beschreibung des Pakets"

[build]
entry = "main.lyx"

[dependencies]
std.string    = "^1.0.0"
anderes.paket = "^2.1.0"

---

mein.paket/
├── lyx.toml          ← Pflicht
├── main.lyx          ← Einstiegspunkt (gemäß entry in lyx.toml)
├── core/
│   └── util.lyx
└── README.md         ← optional

Die unit-Deklaration in jeder Datei muss zum Paketnamen passen:

unit mein.paket;

pub fn main(argc: int64, argv: int64): int64 {
    ...
}

---

Nicht jedes Paket hat eine main-Funktion. Bei einer reinen Bibliothek lässt du den [build]-Abschnitt einfach weg — LPM publiziert das Archiv trotzdem:

[package]
name        = "andreas.stringutils"
version     = "1.0.0"
author      = "Andreas Röne"
license     = "MIT"
description = "Erweiterte String-Hilfsfunktionen für Lyx"

[dependencies]
std.string = "^1.0.0"

Kein entry, kein main. Der Server prüft nicht ob ein Einstiegspunkt vorhanden ist.

Unit-Benennung: Der Paketname aus lyx.toml ist der Namespace-Präfix. Jede Quelldatei deklariert ihre eigene Sub-Unit darunter:

andreas.stringutils/
├── lyx.toml
├── trim.lyx        → unit andreas.stringutils.trim;
├── split.lyx       → unit andreas.stringutils.split;
└── format.lyx      → unit andreas.stringutils.format;

unit andreas.stringutils.trim;

import std.string;
import std.alloc;

pub fn StrTrimLeft(s: int64): int64 { ... }
pub fn StrTrimRight(s: int64): int64 { ... }
pub fn StrTrim(s: int64): int64 { ... }

Nur pub-Funktionen sind nach außen sichtbar.

Nutzer der Bibliothek:

[dependencies]
andreas.stringutils = "^1.0.0"

lpm install

unit mein.projekt;

import andreas.stringutils.trim;
import andreas.stringutils.split;

pub fn main(argc: int64, argv: int64): int64 {
    var s: int64 := StrTrim("  hallo  "c);
    ...
}

lyxc findet die installierten Units über den Cache-Pfad, den lpm als -I-Flag weitergibt — das übernimmt lpm resolve (der lyxc-Hook) automatisch.

Faustregeln:

Ein Hybrid macht Sinn wenn das Paket sowohl eine CLI liefert als auch eine API für andere Pakete — wie z.B. lpm selbst: es hat pub fn main, aber lpm.core.* ist für andere Pakete importierbar.

---

Vor jedem Publish die Version in lyx.toml erhöhen — SemVer:

Bereits veröffentlichte Versionen können nicht überschrieben werden — immer neue Versionsnummer.

---

cd mein.paket/
lpm publish

LPM führt dabei aus:

1. lyx.toml lesen
2. Alle .lyx-Dateien in ein .lxpkg-Archiv packen
3. SHA256 berechnen
4. Hochladen: POST /v1/publish mit Bearer-Token

Erfolgsmeldung:

lpm: [email protected] veröffentlicht (sha256: abc123...)

---

Version in lyx.toml erhöhen, dann erneut publishen:

# lyx.toml: version = "0.2.0"
lpm publish

---

In lyx.toml eines anderen Projekts:

[dependencies]
mein.paket = "^0.2.0"

lpm install

LPM löst die Version auf, lädt das .lxpkg herunter und verifiziert den SHA256.

---

lpm update aktualisiert installierte Pakete auf die neueste Version, die mit der Versionsangabe in lyx.toml kompatibel ist. Die Constraint-Zeilen in lyx.toml bleiben dabei unverändert — nur der tatsächlich installierte Stand wird angehoben.

Alle Abhängigkeiten auf einmal aktualisieren:

lpm update

LPM prüft für jede Abhängigkeit, ob in der Registry eine neuere Version existiert, die noch in den deklarierten Bereich fällt. std.string = „^1.0.0“ erlaubt z.B. jede 1.x.y-Version, nicht aber 2.0.0.

Einzelnes Paket aktualisieren:

lpm update andreas.stringutils

Nützlich wenn nur ein bestimmtes Paket eine kritische Bugfix-Version erhalten hat und der Rest stabil bleiben soll.

Was '^' bedeutet:

Bei 0.x.y-Versionen schützt '^' auch vor Minor-Bumps — solange die Major-Version 0 ist, gilt jede Minor-Erhöhung als potenzieller Breaking Change.

Breaking Change: Major-Version anheben

Wenn ein Paket eine neue Major-Version veröffentlicht (1.x.x → 2.0.0), greift lpm update bewusst nicht — die ^-Constraint verhindert es. Die Abhängigkeit in lyx.toml muss manuell angepasst werden:

[dependencies]
andreas.stringutils = "^2.0.0"   # war: ^1.0.0

lpm install

Das ist Absicht: ein Major-Bump signalisiert Breaking Changes, die eine bewusste Entscheidung erfordern.

---

Letzte Aktualisierung: 2026-06-12