Rye und uv: Im August ist Erntezeit für Python-Packaging

 (lucumr.pocoo.org)
2 Punkte von GN⁺ 2024-08-23 | 1 Kommentare | Auf WhatsApp teilen
  • Nachdem die Verwaltung von Rye im Februar 2024 an Astral überging, wurde der zugrunde liegende Resolver und Installer uv schnell verbessert und entwickelte sich zu einem Kandidaten für die Vereinheitlichung von Python-Packaging-Tools
  • Das aktuelle uv umfasst inzwischen die Bearbeitung von pyproject.toml, Workspace-Unterstützung, Verweise auf lokale Pakete, Skriptinstallation und Verwaltung von Python-Installationen und übernimmt damit Bereiche, die zuvor Rye abdeckte
  • Durch Investitionen in AI und ML gibt es mehr neue Python-Nutzer, doch die vielen Auswahlmöglichkeiten bei Packaging-Tools und uneinheitliche Kompatibilität sorgen weiterhin für eine uneinheitliche Developer Experience
  • Das Packaging-Ökosystem braucht ein dominantes Tool, das alle verwenden, damit Investitionen und Dokumentation in einem Stack zusammenlaufen; Rye dürfte ein Migrationspfad für den Wechsel hin zu uv werden
  • Astrals VC-Finanzierung ist ein Risiko, das die PSF und das Python-Core-Projekt berücksichtigen müssen, doch uv wird als Code eingeschätzt, der selbst im schlimmsten Fall geforkt und weiter gepflegt werden kann

Der Trend von Rye hin zu uv

  • Im Februar 2024 ging die Verwaltung von Rye an Astral über, und in den folgenden Monaten verbesserte Astral die Python-Packaging-Tools schnell
  • Rye-Nutzer konnten spüren, dass der zugrunde liegende Resolver und Installer uv besser und schneller geworden ist
  • Das aktuelle uv bietet inzwischen direkt Funktionen, für die früher Rye nötig war
    • Bearbeitung der Datei pyproject.toml
    • Workspace-Unterstützung
    • Verweise auf lokale Pakete
    • Skriptinstallation
    • Verwaltung von Python-Installationen
  • Wer derzeit Rye nutzt, sollte sich uv ansehen und Astral Feedback geben

Warum Python-Packaging-Tools zusammengeführt werden sollten

  • Der Vortrag auf der EuroPython Prague drehte sich um den aktuellen Zustand des Python-Packagings und die Lektionen aus der Entwicklung von Rye
  • Das Ziel eines Packaging-Tools ist es, zum dominanten Tool in diesem Bereich zu werden
    • Das Tool, das alle verwenden, sollte das beste Tool sein
    • Denn es ist das Tool, dem Menschen begegnen, wenn sie zum ersten Mal mit Python ihre Programmierreise beginnen
  • In den vergangenen zwei Jahren ist Python, getragen von Investitionen und Interesse an AI und ML, für neue Entwickler zu einer sehr heißen und beliebten Plattform geworden
  • Es ist wichtig, dass neue Nutzer Python nicht als veraltete Sprache mit schlechten Tools in Erinnerung behalten, sondern als Sprache mit hervorragender Developer Experience
  • Derzeit gibt es im Python-Packaging jedoch zu viele Optionen, die Kompatibilität zwischen Tools ist nicht vollständig, und Inkonsistenzen an vielen Stellen erschüttern die Erfahrung
    • Manche Nutzer folgen einem Tool, stoßen auf eine Wand, verschieben den gesamten Stack zu conda und kehren dann wieder zurück

Die Möglichkeit, dass uv zum dominanten Tool wird

  • Dass ein Tool eine dominante Position einnimmt, bedeutet, dass der Großteil der Investitionen in einem Stack zusammenläuft
  • Für Rye und verschiedene Tools in seinem Umfeld wäre es wünschenswert, dass sie nicht mehr unabhängig existieren müssen, sobald sich ein dominantes Tool etabliert hat
  • Derzeit gilt uv als das Tool mit der größten Wahrscheinlichkeit, diese Rolle zu übernehmen
    • Es deckt noch nicht alle Use Cases ab
    • Es scheint diesen Punkt aber schnell zu erreichen
  • Jetzt ist der Zeitpunkt, an dem die Community beginnen sollte, sich um uv zu sammeln
  • Das bedeutet nicht, dass dieses Tool für immer das einzige Tool sein wird
    • Tools können entstehen und verschwinden
    • In Zukunft kann auch ein anderes Tool auftauchen

Der Ruhestand von Rye und der Wandel der Anleitung für Python-Projekte

  • Die erwartete finale Version von Rye wird Rye-spezifische Funktionen in den Ruhestand schicken, Nutzer zu uv migrieren und größtenteils wie ein Alias für uv funktionieren
  • Es reicht nicht aus, nur Rye in den Ruhestand zu schicken
    • Derzeit werden in Python mehrere Paketmanagement-Lösungen verwendet
    • Die Community sollte auf weniger Tools verweisen
  • Rye und uv bauen auf einer langen Entwicklung des darunterliegenden Ökosystems auf
    • Der Weg von setup.py über eggs hin zu wheels
    • Der Weg vom Fehlen von Metadatenstandards hin zum Vorhandensein von Standards
    • Der Weg von einem gekoppelten Build-System zu einem entkoppelten Build-System
    • Arbeiten, die weiterverteilbare und herunterladbare Python-Binaries möglich gemacht haben
    • Das Ökosystem aus zugehörigen Rust crates und Python-Bibliotheken
  • Die Community muss bereit sein, irgendwann zu sagen, dass bestimmte Tools nicht mehr empfohlen werden
    • Früher wurden in Einführungsdokumenten für neue Entwickler ez_setup.py und easy_install empfohlen
    • Später wurde ez_setup.py aus den Anleitungen entfernt und durch pip ersetzt
    • Einige Projekte verwiesen auf pip-tools, poetry und PDM
    • Heute zeigen viele Projekte wegen der Vielzahl an Tools auch fünf Installationsanleitungen gleichzeitig
  • Maintainer wichtiger Python-Projekte sollten uv selbst ausprobieren und prüfen, ob sie ihre Nutzer auf uv verweisen können
  • Der Beitrag von Astrals Charlie darüber, was uv heute leisten kann, zeigt die aktuellen Erfolge von uv

Astrals VC-Finanzierung und Risiken für die Community

  • Dass Astral, das uv entwickelt, ein Unternehmen mit VC-Finanzierung ist, ist ein unvermeidlicher Streitpunkt
  • Aus Sicht der Community kann es neue Herausforderungen schaffen, wenn jemand viel Geld einbringt
  • Die PSF und das Python-Core-Projekt müssen diesen Punkt berücksichtigen
  • Betrachtet man den Code und das Verhalten von uv, wirkt es selbst in der schlechtesten Zukunft wie ein Projekt, das geforkt und weiter gepflegt werden kann
  • Selbst wenn Astral schließen oder lizenzseitig äußerst fragwürdige Dinge tun sollte, könnte die Community in einer besseren Position sein als vor der Existenz von uv

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-23
Hacker-News-Kommentare

  • Das neueste Release von uv wurde auch gestern schon diskutiert: https://news.ycombinator.com/item?id=41302475
    Der verlinkte Beitrag ist eine Einschätzung, die der Autor von Rye nach Sichtung dieses Releases geschrieben hat.

  • Für alle, die sich für uv interessieren: Beim Release-Prozess von Home Assistant hat der Einsatz von uv statt pip die Geschwindigkeit massiv erhöht.
    Die Release-Zeit sank von etwa 2,5 Stunden auf etwa 20 Minuten; Details stehen unter https://developers.home-assistant.io/blog/2024/04/03/build-i.... Zur Einordnung: Ich bin nur ein HA-Nutzer.

    • Ich verstehe nicht, wie pip für das Erstellen von Images über eine Stunde brauchen konnte, obwohl es nicht einmal eine kompilierte Sprache ist.
      Ich nutze Python eher leichtgewichtig, aber ich habe keine Ahnung, was da so lange gedauert haben soll; das fühlt sich absurd an.

  • Ich weiß, dass es Probleme beim Python-Packaging gibt, aber ich persönlich bin bisher mit plain pip schon ziemlich weit gekommen.
    Die größte Änderung war für mich der Wechsel von virtualenv zum eingebauten venv-Modul. Wenn ich Dependency-Management wirklich ernsthaft angehen müsste, würde ich vermutlich im FAANG-Stil ein Monorepo bauen und den ganzen Ärger rund um Paketmanager vermeiden.

    • Ich kann nur wirklich empfehlen, ein Monorepo selbst einmal auszuprobieren.
      Ich betreue ein Python-Monorepo in Produktion, und Dependency-Management ist die Hölle. Ich versuche, ein paar der neuen Features von Poetry einzusetzen, aber der Zustand des Ökosystems rund um große Monorepos ist furchtbar.
    • Darüber sollte man tiefer nachdenken.
      Das Ziel ist nicht „für mich reicht es“, sondern Standardwerkzeuge für Pakete und virtuelle Umgebungen, die von einer Organisation mit zwei Python-Entwicklern bis hin zu Hunderten oder Tausenden skalieren. Sonst zersplittert das Ökosystem, und mehr Bugs sowie schwer verständliche Dokumentation machen es der Sprache schwer, sich effektiv weiterzuentwickeln.
    • Wenn einem die Python-Version egal ist, halte ich pip + venv auch für ausreichend.
      Es gibt aber keine Möglichkeit zu definieren, auf welche Python-Version ein Projekt ausgerichtet ist. Wenn man ein Paket baut, muss man es wahrscheinlich gegen mehrere Versionen testen; und wenn es kein installierbares Distribution-Paket ist, sondern nur ein Code-Bündel, das sich ein paar Entwickler teilen, dann will man für Dinge wie das Ausführen von ML-Modellen, das Deployen von Cloud-Funktionen oder das Erzeugen von Reports normalerweise genau eine Python-Version als Ziel festlegen.
      Ich frage mich außerdem, ob mit dem Monorepo-Ansatz gemeint ist, numpy und pandas einfach ins Repository zu kopieren.
    • Meine Erfahrung ist exakt dieselbe: pip reicht für mich aus.

  • Anfangs hatte ich gehofft, ein neues Tool würde das „Packaging“-Problem von Python lösen, aber je mehr ich las, desto klarer wurde: Es geht hier eher um Paketmanagement als um das Verpacken von Python-Anwendungen, die ich erstellt habe.
    Ich persönlich hatte nie große Probleme mit dem Python-Paketmanagement; dem Ökosystem fehlt zwar einiges, aber abgesehen von Dingen wie fehlenden Namespaces funktioniert pip meist ordentlich.
    Wirklich frustrierend ist, dass man Python-Anwendungen nicht einfach in eine ausführbare Datei einpacken und irgendwohin deployen kann. Ich sehe oft, dass in Produktionsumgebungen git clone und das Anlegen einer virtualenv gemacht werden, wodurch das Zielsystem mehr Konnektivität braucht als nötig und Entwicklungsabhängigkeiten im Betriebssystem zurückbleiben. Aus Sicherheitssicht ist das eine sehr schlechte Idee; solange dieses Problem nicht gelöst ist, würde ich für Dinge mit Endnutzer- oder Produktions-Deployment lieber andere Sprachen wählen.

    • Das ist nicht falsch, aber heruntergebrochen heißt der Kernpunkt: Andere Leute sollen Anwendungen leicht ausführen können.
      Dafür muss die Anwendung zum Nutzer gelangen, dort Python finden, und dieser Prozess muss für den Nutzer transparent sein. Einer der Gründe, warum ich beim Bau von Rye — und bei uv genauso — die Installation von Python unterstützen wollte, war genau das, und zwar auf eine Weise, die das System nicht kaputtmacht.
      Die weiterentwickelte Form davon ist, den gesamten Ablauf inklusive uv zu automatisieren. Schon heute kann man, wenn man möchte, einen Curl-to-bash-Installer verwenden, der uv/Rye und die App an einem app-spezifischen temporären Ort installiert, ohne das System des Nutzers jemals zu beschädigen.
      Irgendwann wäre es schön, wenn dieser Prozess völlig transparent würde, keinen Netzwerkzugriff mehr bräuchte und es auch etwas wie eine .msi für Windows gäbe. Die Voraussetzung dafür ist allerdings, dass ein Tool wie uv vorkompiliertes Python und alle nötigen Dependencies passend zur Plattform des Nutzers beliebig platzieren kann.
      Der ultimative Bonus, den uv irgendwann liefern könnte, wäre ein vollständig verpacktes Ergebnis — und das wäre großartig. Schon der Zwischenschritt könnte aber die Erfahrung, Python-basierte Kommandozeilen-Tools an Nutzer auszuliefern, von schrecklich zu erträglich machen. Man könnte uvx verwenden oder uv auf Wunsch auch vollständig verbergen.
    • Es hängt davon ab, wo und was man installieren will, aber für vernünftige Deployment-Ziele gibt es normalerweise ein Tool, das installierbare Binärdateien für genau dieses Ziel erzeugt.
      Es gibt zum Beispiel Tools, die Installer für verschiedene Betriebssysteme erstellen, und inzwischen auch welche für exotischere Ziele wie Android, iOS oder den Browser. Natürlich kann es sein, dass ein bestimmtes Paket auf einem bestimmten Ziel nicht funktioniert, aber es gibt eine Standard-Schnittstelle; wenn der Code also irgendwo lauffähig ist, sollte ein zielgerichtetes Tool dafür ein funktionsfähiges Ergebnis erzeugen können.

  • Seit dem Venture-Capital-getriebenen Rug Pull bei npm und der Übernahme durch Microsoft, und nachdem OpenAI gezeigt hat, dass sogar ein rechtlicher Non-Profit-Status für Führungspersonen auf Venture-Pfaden nur machtloses Marketing ist, widerstrebt es mir, Sprachinfrastruktur auf dem kritischen Pfad solchen Organisationen zu überlassen
    Die Einzelpersonen, die dazu beitragen, sind jeweils großartig und oft hervorragend, aber die finanziellen Interessen auf Organisationsebene sind von Anfang an vergiftet. Nach 1 bis 4 Jahren zählt die Organisation. Es ist dieses „Entweder man stirbt als Held, oder man lebt lange genug, um zum Bösewicht zu werden“
    Deshalb sind schnelle Linter, Typprüfungen, Code-Scanner und PR-Hilfswerkzeuge okay und jederzeit austauschbar. Aber Installations-Workflows und Paket-Repositories nicht
    Wenn man an den Zustand von pip und conda denkt, ist das bedauerlich, aber ich glaube, so ist die Realität

    • In Python ist dieser Kampf bereits verloren
      Ich denke, Microsoft besitzt Python, zeigt es nur nicht offen
      Vor ein paar Jahren wollte ich Python-Bindings für kubectl bauen und habe festgestellt, dass CGo plattformübergreifend auf allen Plattformen denselben Compiler wie Python verwenden muss. Unter Windows nutzt CGO aber MINGW, während Python MSVC verwendet. Ich habe damals auf der Python-Developer-Mailingliste gefragt, warum ein „Open-Source“-Projekt einen proprietären Compiler verwendet, und die Antwort war, dass MSVC eine historische Entscheidung sei und man das jetzt nicht mehr ändern könne. Erklärt wurde das damit, dass Microsoft der Python Foundation kostenlose Infrastruktur für CI und Builds bereitstellt und auch Entwickler stellt, die am Python-Interpreter arbeiten. Das bedeutete also, dass Microsoft-Mitarbeiter mit Microsoft-Geld am Python-Interpreter arbeiten und die Anweisung haben, Microsoft-Werkzeuge nicht aus der Toolchain zu entfernen
      Jedes Jahr wurde die Situation schlimmer. Wie bei ähnlichen Projekten schuf der Erfolg einen Nährboden dafür, dass Leute ohne besondere Kompetenz Machtpositionen bekamen, und Projekte im Umfeld wie die Python Foundation und die PyPA füllten sich zunehmend mit Leuten, die ihre Position nicht durch nützlichen Code, sondern durch das Schreiben von Verhaltenskodex-Seiten erhielten. Die endlosen Streitigkeiten um diesen Verhaltenskodex und die Kontrolle über Positionen führten schließlich dazu, dass langjährige Mitwirkende gingen oder verdrängt wurden; zuletzt wurde sogar Tim, der Tim sort entwickelt hat, ausgeschlossen
      Microsoft drückt weiter die übliche Agenda durch, die es in jedes Projekt bringt, das es anfasst. Es fügt jede Menge nutzlose Features für Marketingzwecke hinzu, bringt das Projekt in alle möglichen Richtungen ins Schlingern und sorgt besonders dafür, dass es Trends maximal hinterherläuft. Deshalb bekommt Python so viel maschinelles Lernen bei den Typen aufgedrückt, obwohl es eine Sprache mit einem völlig anderen Typsystem ist, und hängt an Ahead-of-Time-Kompilierung und JIT, obwohl die Sprache zur Hälfte dafür verwendet wird, native Bibliotheken dynamisch anzubinden. Im Wesentlichen wird sie zu C# ohne geschweifte Klammern gemacht
      Microsoft ist klug genug, die Übernahme von Python nicht offen auszurufen, weil viele Leute sich dann von der Technologie abwenden würden. Aber es sorgt weiter dafür, dass Entwickler von den eigenen Werkzeugen abhängig werden, und irgendwann wird es kommen, um diese Investition zu monetarisieren
    • War npm nicht von Anfang an ein Unternehmen? Ich weiß nicht, was mit Rug Pull gemeint ist, und ob tatsächlich irgendetwas aufgehört hat zu funktionieren?
    • Ich begrüße es jederzeit, wenn PSF und PyPA sich fangen und etwas Gutes zum Python-Packaging liefern
      Aber bisher kam im Wesentlichen nur eine Milliarde Contributor-Blogposts heraus, die sinngemäß sagen: „Das System, das wir gebaut haben, schränkt uns darin ein, hilfreich zu sein, und jedenfalls ist das nicht unsere Schuld“
      Sie scheinen so sehr in ihre internen Systeme und ihre interne Politik verstrickt zu sein, dass sie gar nicht mehr wissen, warum sie überhaupt da sind
      Wenn also jemand tatsächlich gute Arbeit macht und wie Astral den Markt übernimmt, dann ist das genau das Ergebnis, das wir als Community verdienen
      [1]: Gemeint ist hier interne Politik. Nicht seltsames rechtsextremes „DEI-Hiring!“-Geschrei

  • Bei diesen Tools bleibt immer noch das Problem der Autorität
    Anders als cargo sind sie nicht von der PyPA abgesegnet. Gleichzeitig hat die PyPA über Jahre keine umfassende Lösung geliefert, während Python-Packaging und Entwicklungswerkzeuge sich immer weiter vermehrt haben. Noch vor gerade einmal 3 bis 4 Jahren sah es so aus, als würden poetry und pipenv Probleme im Python-Packaging lösen, die sich mit pip+virtualenv nicht lösen ließen
    Ich denke inzwischen, die PyPA sollte auf das Schiff von astral.sh aufspringen, aber ich weiß nicht, ob sie das ohne ein gewisses Maß an Kontrolle tun wird

    • Ich habe erst vor Kurzem gelernt, dass bei der PyPA, also Python Packaging Authority, Authority ursprünglich als Witz gemeint war: https://discuss.python.org/t/remove-the-authority-from-packa...
    • Seit die PyPA Pipenv gegenüber anderen Optionen abgesegnet hat, ignoriere ich Empfehlungen der PyPA
      Soweit ich das beurteilen kann, lag das zu einem erheblichen Teil an persönlichen Beziehungen, und Pipenv war damals katastrophal. Die Absicht war gut, aber im Unternehmen musste man selbst in Repositories mit relativ wenigen und weit verbreiteten Abhängigkeiten eine Stunde warten, um die Lock-Datei zu aktualisieren. Es funktionierte einfach nicht
      Praktisch gesehen bin ich für die schwierige technische Arbeit der PyPA sehr dankbar. Aber es ist mir ziemlich egal, welches Tool-Bündel sie heute empfiehlt. Ich denke, es ist besser, einfach das zu verwenden, was die Community benutzt, und sich nicht um „offizielle“ Vorschläge zu kümmern
    • Als eher außenstehender Beobachter verstehe ich nicht so recht, was die PyPA eigentlich ist
      Wie viele Beteiligte es gibt, ist unklar, und auch in welchem Maß die PyPA mit dem Python-Kern oder der PSF verbunden ist, ist nicht wirklich eindeutig
      Eine tatsächlich hilfreiche Empfehlung müsste meiner Meinung nach vom eigentlichen Python-Kernprojekt kommen. In einer idealen Welt würde das offizielle Python-Tutorial mit „So installiert man Python“ beginnen und direkt zur Installation von uv anleiten, so wie die offizielle Rust-Dokumentation auf rustup und cargo verweist
      Ich hoffe sehr, dass die PSF irgendeine Beziehung zu Astral aufbaut, sodass so eine Realität irgendwann möglich wird
    • Ehrlich gesagt ist mir die PyPA an diesem Punkt egal
      In diesem Zusammenhang hat sie meiner Meinung nach selbst bewiesen, dass sie weitgehend irrelevant ist. Alles, was sie anfasst, scheint zu verrotten, und so bedauerlich das ist, ich hätte lieber, sie hielte sich bei diesem Problem fern. Das zu sagen ist unerquicklich und widerspricht meiner Philosophie, aber es ist einfach ein Urteil, das den aktuellen Zustand widerspiegelt. Ich arbeite seit 10 Jahren Vollzeit mit Python, und andere Packaging-Ökosysteme haben Python inzwischen effektiv um mehr als eine Runde überholt
      Mich interessieren inzwischen nicht einmal mehr Nuancen wie „Liegt es an Ausführungsproblemen der PyPA oder ist ihr zugeschnittener Aufgabenbereich falsch“. Ich bin es leid, überhaupt in diese Diskussion hineingezogen zu werden

  • Armin plädiert dafür, dass uv diesen Bereich dominiert, räumt aber auch ein, dass es aufgrund der Venture-Capital-Basis zu einem Rug Pull kommen könnte
    Als Lösung für dieses potenzielle Problem sagt er: „Es ist sehr leicht zu forken“ — aber führt ein Fork nicht im Kern zu noch mehr Fragmentierung? Also genau zu dem Problem, das er lösen will
    Wenn ein Tool die Python-Packaging-Landschaft dominieren soll, dann sollte die Community es vorantreiben und kontrollieren

    • Ein Fork führt nicht zwangsläufig zu mehr Fragmentierung
      Der Grad der Fragmentierung nach einer zunächst erreichten Vereinheitlichung auf ein rug-pulltes Tool könnte immer noch deutlich geringer sein als vor dieser Vereinheitlichung
      Und wie viele weitere Jahrzehnte braucht diese imaginäre Community noch, um ein großartiges dominantes Tool zu bauen?
    • Die Wahl einer MIT- oder Apache-Lizenz macht Forks zwar einfach, aber die Wahl von Rust begrenzt in der Praxis die Zahl der Leute, die tatsächlich beitragen können
    • Ist npm nicht auch Venture-Capital-finanziert?

  • Heute Morgen haben wir bei der Arbeit wegen der Langsamkeit von Poetry geprüft, unsere Software von Poetry auf uv zu migrieren
    Bisher lese ich vor allem viel Dokumentation, aber praktisch komme ich kaum voran. Die frühere Migration zu Poetry habe ich ebenfalls gemacht, und die war viel einfacher. So wie es bisher aussieht, wollte Poetry einen einfachen Paketmanager bauen, der sich wie andere Paketmanager verhält, während uv anscheinend einen guten Teil des Wahnsinns von Python-Paketen unverändert beibehält

    • Immerhin gerät uv nicht wie Poetry mit virtualenv in Konflikt und verwandelt alles in ein komplettes Chaos
      Auch gibt es keine kleinen Poetry-Änderungen, die das package.toml-Format kaputtmachen, oder diese dämlichen „sources“, die bei mehreren Indizes die Auflösungszeit verlängern, obwohl sie für transitive Abhängigkeiten nicht funktionieren
    • Kannst du konkret teilen, was bei uv schwierig war?
    • Ich bin vor Kurzem von pip-tools zu uv gewechselt, und das lief ziemlich reibungslos
      uv fühlt sich tatsächlich so an, als würde es sich direkt in den standardmäßigen Python-Tool-Workflow einfügen
    • Ist uv derzeit nicht zu Low-Level — wolltest du vielleicht eher Rye?
    • Welchen Wahnsinn meinst du genau?

  • Ich würde es niemandem verübeln, diese Runde auszulassen und auf die Ausgabe 2026 von „Python-Paketmanager: Diesmal haben wir es wirklich gelöst!“ zu warten
    Ich bin trotzdem weiterhin ein zufriedener Nix-Nutzer

  • Dieses Framing gefällt mir wirklich
    Dank der Arbeit, die viele Menschen über lange Zeit schrittweise aufgebaut haben, sind wir jetzt an einem Punkt, an dem ein paar Leute in einem Unternehmen mit mäßigem Aufwand die Lage plötzlich stark verbessern können