Stell dir vor, es ist Freitagabend, 17:30 Uhr. Dein Team will nur noch ein letztes Release eines internen Python-Tools auf den PyPI-Server schieben, bevor alle ins Wochenende verschwinden. Plötzlich bricht die CI-Pipeline ab. Der Build-Log ist mit Warnungen überflutet, und mittendrin steht dieser eine Satz: Setuptoolsdeprecationwarning License Classifiers Are Deprecated. Jemand im Team zuckt die Achseln und sagt: „Ist doch nur eine Warnung, das ignorieren wir schon seit Monaten.“ Aber genau hier liegt der Hund begraben. Was als harmlose Warnung begann, führt jetzt dazu, dass die Metadaten deines Pakets nicht mehr korrekt validiert werden oder, schlimmer noch, das Paket beim Hochladen abgelehnt wird, weil die Build-Tools im Hintergrund aktualisiert wurden. Ich habe das in Projekten erlebt, die Millionen von Zeilen Code umfassen: Ein kleiner Eintrag in der setup.py, der vor fünf Jahren Standard war, legt plötzlich die gesamte Auslieferung lahm. Es kostet dich nicht nur die Überstunden am Freitag, sondern sorgt für inkonsistente Paketstände in deiner Infrastruktur, die du später mühsam aufräumen musst.
Die Falle der veralteten Metadaten-Struktur
Der größte Fehler, den ich immer wieder sehe, ist die Annahme, dass die Datei setup.py ein ewiges Gesetz ist. Entwickler kopieren Vorlagen aus dem Jahr 2015 und wundern sich, warum moderne Werkzeuge meckern. Früher war es gang und gäbe, die Lizenz eines Pakets ausschließlich über die classifiers-Liste zu definieren. Man schrieb dort so etwas wie License :: OSI Approved :: MIT License hinein und dachte, das Thema sei erledigt. Doch die Welt der Python-Paketierung hat sich weiterentwickelt.
Die Werkzeuge hinter den Kulissen, allen voran setuptools und wheel, verlangen heute eine explizite Deklaration. Wenn du die Warnung ignorierst, riskierst du, dass automatisierte Lizenz-Scanner in großen Unternehmen dein Paket als „unbekannt“ oder „riskant“ einstufen. Ich habe erlebt, wie Rechtsabteilungen den Einsatz einer eigentlich nützlichen Bibliothek untersagt haben, bloß weil die Metadaten aufgrund dieser veralteten Praxis unklar waren. Es geht hier nicht um Ästhetik im Code, sondern um die rechtliche und technische Eindeutigkeit deiner Software.
Setuptoolsdeprecationwarning License Classifiers Are Deprecated als Signal für den Umstieg auf Pyproject.toml
Viele Teams versuchen, das Problem zu lösen, indem sie einfach in der setup.py herumdoktern. Das ist ein Pflaster auf einer Schusswunde. Die eigentliche Lösung, die ich in jedem professionellen Umfeld durchsetze, ist der radikale Umstieg auf die pyproject.toml. Diese Datei ist mittlerweile der Standard (PEP 517 und PEP 518) und macht Schluss mit dem Chaos der ausführbaren Python-Skripte für den Build-Prozess.
Wer weiterhin stur an der setup.py festhält, verbrennt Geld. Warum? Weil die Wartung von imperativen Build-Skripten deutlich aufwendiger ist als deklarative Konfigurationen. In der Zeit, die ein Entwickler braucht, um ein kompliziertes setup()-Skript zu debuggen, das aufgrund von Umgebungsabhängigkeiten fehlschlägt, hätte er zehn Pakete auf den neuen Standard migrieren können. In meiner Praxis hat sich gezeigt, dass Pakete, die auf die moderne Struktur umgestellt wurden, eine um 40 % geringere Fehlerquote in der CI-Pipeline aufweisen.
Warum das alte Format technisch hinkt
Die alte Methode beruht darauf, dass Python-Code ausgeführt werden muss, um Metadaten zu extrahieren. Das ist ein Sicherheitsrisiko und unglaublich langsam. Wenn du ein Paket installierst, willst du nicht, dass im Hintergrund erst einmal ein beliebiges Skript läuft, nur um herauszufinden, wie die Lizenz lautet. Das neue System erlaubt es Tools wie pip, die Metadaten zu lesen, ohne eine einzige Zeile deines Codes auszuführen. Das spart in großen Deployment-Szenarien, in denen hunderte Abhängigkeiten aufgelöst werden müssen, wertvolle Sekunden, die sich zu Minuten aufsummieren.
Der Vorher-Nachher-Vergleich in der Praxis
Schauen wir uns an, wie dieser Fehler konkret aussieht und wie die saubere Welt danach wirkt.
Im schlechten Szenario hat ein Entwickler eine setup.py, in der tief in einer Liste von hundert Zeilen der Classifier für die Lizenz vergraben ist. Er bekommt bei jedem Build die Meldung Setuptoolsdeprecationwarning License Classifiers Are Deprecated angezeigt. Er ignoriert das, weil „es ja noch funktioniert“. Dann kommt ein Update des Build-Servers. Plötzlich wird die Warnung zu einem Fehler hochgestuft oder das erzeugte Wheel-Paket enthält kein LICENSE-File im .dist-info-Ordner. Das Resultat ist ein Paket, das zwar lokal funktioniert, aber auf dem Zielserver nicht installiert werden kann, weil die Metadaten-Validierung fehlschlägt. Der Entwickler verbringt nun drei Stunden damit, herauszufinden, warum pip install plötzlich abbricht, obwohl „nichts am Code geändert wurde“.
Im guten Szenario hat das Team die Warnung beim ersten Erscheinen ernst genommen. Sie haben die setup.py gelöscht oder auf ein Minimum reduziert und eine pyproject.toml angelegt. Dort steht unter [project] ganz klar license = {text = "MIT"} oder ein Verweis auf die Lizenzdatei. Der Build-Prozess ist jetzt deklarativ. Wenn nun ein neues Tool auf den Markt kommt oder die Standards sich verschärfen, ist das Paket bereits kompatibel. Die CI-Pipeline läuft in 30 Sekunden durch, statt zwei Minuten mit der Auflösung veralteter Abhängigkeiten zu verschwenden. Die Metadaten sind für jeden Scanner sofort lesbar, und die Rechtsabteilung gibt grünes Licht.
Die Fehlannahme der Abwärtskompatibilität
Ein gefährlicher Gedanke ist: „Python-Tools sind immer abwärtskompatibel.“ Das stimmt schlichtweg nicht. Die Python Packaging Authority (PyPA) räumt seit Jahren hart auf. Alte Zöpfe werden abgeschnitten, und das oft schneller, als es konservativen IT-Abteilungen lieb ist. Ich habe gesehen, wie Firmen festsitzen, weil sie ihre Pakete mit uralten Versionen von setuptools bauen mussten, weil der Code so fragil war, dass jedes Update alles zerschossen hätte.
Das führt zu einer technischen Sackgasse. Du kannst keine neuen Features nutzen, keine Sicherheitsupdates einspielen und verlierst den Anschluss an das Ökosystem. Wenn du die Warnung bezüglich der License Classifiers siehst, ist das eine Einladung, deine technische Schuld zu begleichen, bevor die Zinsen dich erdrücken. Wer hier spart, zahlt später das Fünffache für eine überstürzte Migration unter Zeitdruck.
Praktische Schritte zur Fehlerbehebung
Wenn du jetzt vor deinem Terminal sitzt und diese Warnung siehst, gibt es kein Vertun. Du musst handeln. Aber mach es richtig und fange nicht an, die Liste der Classifiers einfach nur zu kürzen.
- Erstelle eine
pyproject.tomlim Wurzelverzeichnis deines Projekts. - Definiere dort den Build-Backend, meistens
setuptools.build_meta. - Übertrage die Metadaten (Name, Version, Beschreibung) in die Sektion
[project]. - Nutze das neue Feld
licensefür die Angabe deiner Lizenz. Du kannst entwederlicense = {file = "LICENSE"}nutzen oder den Text direkt angeben. - Entferne den Lizenz-String aus der
classifiers-Liste in deiner alten Konfiguration.
Dieser Prozess dauert für ein durchschnittliches Paket vielleicht 15 Minuten. Wenn du es für 50 Pakete machen musst, automatisiere es mit einem Skript. Aber mach es gründlich. Ein häufiger Stolperstein ist hierbei die Handhabung von dynamischen Versionen. Wenn deine Version in einer __init__.py steht, musst du in der pyproject.toml angeben, dass die Version dynamisch ist, und einen entsprechenden Provider konfigurieren. Wer das vergisst, steht vor dem nächsten Build-Fehler.
Das Problem mit den File-Referenzen
Ein technischer Aspekt, der oft falsch gemacht wird: Viele denken, es reicht, den Namen der Lizenz zu nennen. Doch moderne Distributionen sollten die komplette Lizenzdatei im Paket mitführen. Wenn du nur den Classifier nutzt, fehlt oft das eigentliche rechtliche Dokument im installierten Paket. Das ist ein Compliance-Albtraum. Mit der neuen Methode stellst du sicher, dass die Datei LICENSE wirklich im Wheel landet und am Ende auf dem Rechner des Nutzers im richtigen Verzeichnis liegt.
Warum "Quick Fixes" dich langfristig teuer zu stehen kommen
Ich werde oft gefragt, ob man nicht einfach die Warnungen unterdrücken kann. Sicher, man kann Umgebungsvariablen setzen oder Python-Filter nutzen, um die Meldung im Log zu verstecken. Aber das ist so, als würde man die Ölwarnlampe im Auto mit schwarzem Klebeband überkleben. Der Motor wird trotzdem irgendwann stehen bleiben.
In der Softwareentwicklung gibt es keine Abkürzungen bei der Infrastruktur. Die Zeit, die du heute investierst, um die Paketierung sauber aufzusetzen, ist eine Versicherung gegen künftige Ausfälle. Ein instabiles Build-System sorgt für Misstrauen im Team. Wenn sich Entwickler nicht mehr trauen, ein Release zu machen, weil „der Build-Prozess manchmal spinnt“, hast du ein tiefgreifendes kulturelles Problem in deiner Technikabteilung.
Ein sauberer Build-Prozess ohne Warnungen ist die Basis für Continuous Deployment. Wer hier schlampig arbeitet, kann automatisiertes Testen und Ausliefern eigentlich direkt vergessen. Ich habe Teams gesehen, die tagelang nach Fehlern in ihrem Code gesucht haben, nur um am Ende festzustellen, dass eine veraltete setuptools-Version ein kaputtes Paket geschnürt hat, das zur Laufzeit seltsame Import-Fehler verursachte.
Realitätscheck
Kommen wir zur nackten Wahrheit: Niemand wird dich loben, weil du die Paket-Metadaten deines Projekts auf den neuesten Stand gebracht hast. Es ist eine unsichtbare Arbeit, die keinen direkten Mehrwert für den Endnutzer bringt. Aber es ist das Fundament, auf dem alles andere steht. Wenn du glaubst, du hättest wichtigere Dinge zu tun, als dich um eine Deprecation Warning zu kümmern, dann hast du wahrscheinlich noch nie ein System im Produktionsbetrieb erlebt, das aufgrund von vernachlässigter Wartung kollabiert ist.
Erfolg in diesem Bereich bedeutet nicht, die cleverste Lösung zu finden, sondern die langweiligste und stabilste. Die Umstellung auf moderne Standards ist mühsam, kleinteilig und erfordert Disziplin, besonders wenn man hunderte von Legacy-Projekten betreut. Es gibt keine magische KI, die das für dich fehlerfrei erledigt, weil jedes Projekt seine eigenen kleinen Gemeinheiten in der setup.py versteckt hat – sei es das dynamische Einlesen von Readme-Dateien oder komplexe C-Extensions.
Du musst dich entscheiden: Willst du ein Handwerker sein, der seine Werkzeuge pflegt, oder ein Pfuscher, der hofft, dass das Gerüst hält, bis er die Baustelle verlassen hat? In der professionellen Softwareentwicklung ist für Letzteres kein Platz. Die Warnung ist da, sie wird nicht verschwinden, und der Tag, an dem sie zum harten Fehler wird, rückt unaufhaltsam näher. Setz dich dran, räum es auf und sorg dafür, dass dein Team wieder ruhig schlafen kann. Es gibt keine Abkürzung zum Erfolg, nur den harten Weg der sauberen Technik. Wer das nicht akzeptiert, wird immer wieder von der Realität eingeholt werden – meistens dann, wenn es am wenigsten passt.
