Paketmanager: pip, npm, Maven Central
In L2 hast du Build-Tools kennengelernt – sie kompilieren und packen deinen Code. Aber kein Projekt steht alleine: jedes nutzt Bibliotheken – Code von anderen, der bestimmte Aufgaben löst. Wer holt diese Bibliotheken in dein Projekt? In welcher Version? Wie hält man die aktuell? Das ist die Aufgabe der Paketmanager.
Die drei wichtigsten: pip (Python), npm (JavaScript/TypeScript), Maven Central (Java). In dieser Lektion lernst du, wie Paketmanager funktionieren, was Version Constraints (z.B. ^4.18.0) bedeuten, was Lock-Files sind, und welche Sicherheitsrisiken in der Abhängigkeitskette stecken.
1) Warum überhaupt Paketmanager?
Stell dir vor, du brauchst eine Bibliothek für PDF-Generierung. Ohne Paketmanager würdest du:
- Google nach „Java PDF library" durchsuchen.
- Eine JAR-Datei manuell herunterladen.
- In den Klassenpfad legen.
- Beim Compile angeben.
- Bei einem Update: neue JAR finden, ersetzen.
- Hoffen, dass die JAR nicht selbst von 5 anderen JARs abhängt – die du dann auch holen musst.
Das letzte Problem ist der Killer: transitive Abhängigkeiten. Bibliothek A braucht B, B braucht C, C braucht D mit einer ganz bestimmten Version. Wer das von Hand verwaltet, ist verloren.
Paketmanager lösen genau das: du sagst „ich will Bibliothek A", sie holen automatisch B, C, D in den passenden Versionen. Eine geniale Erfindung.
2) Der Dependency-Tree
Was passiert eigentlich, wenn du eine einzige Bibliothek installierst? Hier ein typischer Dependency-Tree für ein Express.js-Projekt:
npm install express zieht typischerweise 40-80 transitive Pakete nach. In großen Projekten kommen schnell 1.000+ Pakete zusammen. Ohne Paketmanager unmöglich zu verwalten – mit Paketmanager ist es ein Befehl. Wer die Tiefe sehen will: npm ls (JS), mvn dependency:tree (Java), pipdeptree (Python) zeigen den vollen Baum.3) Die drei großen Paketmanager im Vergleich
pypi.org). Konfiguration in requirements.txt oder modern in pyproject.toml. Pakete werden in das virtuelle Environment (venv) installiert, isoliert pro Projekt.npmjs.com) mit über 3 Mio. Paketen. Konfiguration in package.json. Pakete landen in node_modules/. Alternativen: yarn und pnpm, kompatibel aber schneller.4) Versions-Specifier verstehen
Im package.json siehst du Einträge wie "express": "^4.18.0". Was bedeutet das ^? Versions-Specifier sind eine eigene Mini-Sprache, die in IHK-Klausuren gerne abgefragt wird:
package.json selten – zu starr.package.json. Setzt SemVer voraus.^.^4.0.0.^ erlaubt alle Features-Updates (4.18 → 4.99), aber kein Major-Sprung (kein 5.0).5) Das Lock-File-Konzept
Ein subtiles Problem: dein package.json sagt ^4.18.0. Heute installierst du, bekommst 4.18.2. Morgen wird Version 4.19.0 veröffentlicht. Dein Kollege macht npm install – bekommt 4.19.0. Plötzlich verhält sich euer Projekt unterschiedlich.
Lösung: Lock-Files. Sie fixieren die exakten Versionen aller Pakete (auch transitiv). Wer das Lock-File hat, bekommt garantiert die gleichen Versionen wie der Originalentwickler:
package-lock.json committen, node_modules/ ignorieren. Maven hat traditionell kein Lock-File-Konzept – es wird über exakte Versionen in der pom.xml gelöst. Gradle hat optional gradle.lockfile.6) Public vs. Private Repositories
Die zentralen Repositories sind öffentlich – jeder kann Pakete hochladen, jeder herunterladen. In Firmen will man aber oft eigene Pakete privat halten:
- Firmen-Bibliotheken: intern entwickelter Code, der nicht öffentlich werden soll.
- Lizenz-Schutz: kostenpflichtige Pakete (z.B. Datenbank-Treiber).
- Mirror: Cache der öffentlichen Pakete, falls die Quelle ausfällt.
Lösungen: Nexus Repository, JFrog Artifactory, GitHub Packages, AWS CodeArtifact. In großen Firmen Standard – Builds laufen primär gegen den internen Repo, nicht direkt gegen Maven Central oder npmjs.com.
7) Sicherheitsrisiken in der Lieferkette
Wer fremden Code in sein Projekt holt, übernimmt sein Risiko. Das ist eines der größten Sicherheits-Themen moderner Software:
requestz (statt requests). Tippfehler → infizierter Rechner.8) Workspaces und Monorepos
Größere Projekte bestehen oft aus mehreren Sub-Projekten (Frontend, Backend, Shared-Lib). Statt 3 getrennte Repos zu pflegen, gibt es Monorepos:
- npm Workspaces: seit npm 7. Mehrere
package.jsonin einem Repo, alle teilen sichnode_modules/. - pnpm Workspaces / Yarn Workspaces: ähnliches Konzept, bessere Performance.
- Maven Multi-Module: Parent-pom.xml mit Sub-Modulen.
- Gradle Multi-Project: root + sub-projects, gemeinsame Tasks.
- Nx, Turborepo, Lerna: spezialisierte Monorepo-Tools mit Caching und Task-Graph.
Beispiele: Google, Facebook und Microsoft pflegen riesige Monorepos. Im Mittelstand verbreitet sich der Ansatz auch immer mehr.
9) Best Practices
- Lock-Files committen. Reproduzierbare Builds garantieren.
- node_modules / target / __pycache__ in .gitignore. Niemals binäre Build-Artefakte committen.
- Versionen vorsichtig pinnen. Caret-Ranges (^) für nicht-kritische Bibs OK, exakte Versionen für sicherheitskritische.
- Regelmäßig updaten. Wöchentlich Dependabot-PRs durchsehen.
- Audit-Tools in CI. npm audit, pip-audit, owasp-dependency-check.
- Wenig direkte Abhängigkeiten – jede zusätzliche Bib zieht meist Dutzende mit.
- Lizenzen prüfen bei kommerziellen Produkten.
Zusammenfassung
Paketmanager verwalten Bibliotheken und ihre transitiven Abhängigkeiten. pip (Python, PyPI), npm (JS/TS, npmjs.com), Maven Central (Java, GAV-Koordinaten). SemVer-Specifier: ^4.18.0 (Minor+Patch erlaubt), ~4.18.0 (nur Patch), 4.18.0 (exakt). Lock-Files (package-lock.json, poetry.lock) fixieren genaue Versionen für reproduzierbare Builds. Sicherheit: npm audit, Dependabot. Nächste Lektion: Bibliotheken auswählen.