So, du möchtest zu Dify beitragen – das ist großartig, wir können es kaum erwarten, zu sehen, was du beisteuern wirst. Als ein Startup mit begrenzter Mitarbeiterzahl und Finanzierung haben wir große Ambitionen, den intuitivsten Workflow zum Aufbau und zur Verwaltung von LLM-Anwendungen zu entwickeln. Jede Unterstützung aus der Community zählt wirklich.
Dieser Leitfaden, ebenso wie Dify selbst, ist ein ständig in Entwicklung befindliches Projekt. Wir schätzen Ihr Verständnis, falls er zeitweise hinter dem tatsächlichen Projekt zurückbleibt, und freuen uns über jegliches Feedback, das uns hilft, ihn zu verbessern.
Bezüglich der Lizenzierung nehmen Sie sich bitte einen Moment Zeit, um unser kurzes License and Contributor Agreement zu lesen. Die Community hält sich außerdem an den Code of Conduct.
Finde ein bestehendes Issue, oder öffne ein neues. Wir kategorisieren Issues in zwei Typen:
-
Wenn Sie eine neue Feature-Anfrage stellen, bitten wir Sie zu erklären, was das vorgeschlagene Feature bewirken soll und so viel Kontext wie möglich bereitzustellen. @perzeusss hat einen soliden Feature Request Copilot entwickelt, der Ihnen dabei hilft, Ihre Anforderungen zu formulieren. Probieren Sie ihn gerne aus.
-
Wenn Sie eines der bestehenden Issues übernehmen möchten, hinterlassen Sie einfach einen Kommentar darunter, in dem Sie uns dies mitteilen.
Ein Teammitglied, das in der entsprechenden Richtung arbeitet, wird hinzugezogen. Wenn alles in Ordnung ist, gibt es das Okay, mit der Codierung zu beginnen. Wir bitten Sie, mit der Umsetzung des Features zu warten, damit keine Ihrer Arbeiten verloren gehen sollte unsererseits Änderungen vorgeschlagen werden.
Je nachdem, in welchen Bereich das vorgeschlagene Feature fällt, können Sie mit verschiedenen Teammitgliedern sprechen. Hier ist eine Übersicht der Bereiche, an denen unsere Teammitglieder derzeit arbeiten:
Member Scope @yeuoly Architecting Agents @jyong RAG pipeline design @GarfieldDai Building workflow orchestrations @iamjoel & @zxhlyh Making our frontend a breeze to use @guchenhe & @crazywoola Developer experience, points of contact for anything @takatost Overall product direction and architecture Wie wir Prioritäten setzen:
Feature Type Priority Funktionen mit hoher Priorität, wie sie von einem Teammitglied gekennzeichnet wurden High Priority Beliebte Funktionsanfragen von unserem Community-Feedback-Board Medium Priority Nicht-Kernfunktionen und kleinere Verbesserungen Low Priority Wertvoll, aber nicht unmittelbar Future-Feature
-
Fangen Sie sofort an zu programmieren..
Wie wir Prioritäten setzen:
Issue Type Priority Fehler in Kernfunktionen (Anmeldung nicht möglich, Anwendungen funktionieren nicht, Sicherheitslücken) Critical Nicht-kritische Fehler, Leistungsverbesserungen Medium Priority Kleinere Fehlerkorrekturen (Schreibfehler, verwirrende, aber funktionierende Benutzeroberfläche) Low Priority
Hier sind die Schritte, um Dify für die Entwicklung einzurichten:
Klonen Sie das geforkte Repository von Ihrem Terminal aus:
git clone [email protected]:<github_username>/dify.git
Dify benötigt die folgenden Abhängigkeiten zum Bauen – stellen Sie sicher, dass sie auf Ihrem System installiert sind:
- Docker
- Docker Compose
- Node.js v18.x (LTS)
- pnpm
- Python version 3.11.x or 3.12.x
Dify setzt sich aus einem Backend und einem Frontend zusammen. Wechseln Sie in das Backend-Verzeichnis mit cd api/
und folgen Sie der Backend README zur Installation. Öffnen Sie in einem separaten Terminal das Frontend-Verzeichnis mit cd web/
und folgen Sie der Frontend README zur Installation.
Überprüfen Sie die Installation FAQ für eine Liste bekannter Probleme und Schritte zur Fehlerbehebung.
Um Ihre Einrichtung zu validieren, öffnen Sie Ihren Browser und navigieren Sie zu http://localhost:3000 (Standardwert oder Ihre selbst konfigurierte URL und Port). Sie sollten nun Dify im laufenden Betrieb sehen.
Wenn Sie einen Modellanbieter hinzufügen, ist dieser Leitfaden für Sie.
Wenn Sie einen Tool-Anbieter für Agent oder Workflow hinzufügen möchten, ist dieser Leitfaden für Sie.
Um Ihnen eine schnelle Orientierung zu bieten, wo Ihr Beitrag passt, folgt eine kurze, kommentierte Übersicht des Backends und Frontends von Dify:
Dify’s Backend ist in Python geschrieben und nutzt Flask als Web-Framework. Es verwendet SQLAlchemy für ORM und Celery für Task-Queueing. Die Autorisierungslogik erfolgt über Flask-login.
[api/]
├── constants // Konstante Einstellungen, die in der gesamten Codebasis verwendet werden.
├── controllers // API-Routendefinitionen und Logik zur Bearbeitung von Anfragen.
├── core // Orchestrierung von Kernanwendungen, Modellintegrationen und Tools.
├── docker // Konfigurationen im Zusammenhang mit Docker und Containerisierung.
├── events // Ereignisbehandlung und -verarbeitung
├── extensions // Erweiterungen mit Frameworks/Plattformen von Drittanbietern.
├── fields // Felddefinitionen für die Serialisierung/Marshalling.
├── libs // Wiederverwendbare Bibliotheken und Hilfsprogramme
├── migrations // Skripte für die Datenbankmigration.
├── models // Datenbankmodelle und Schemadefinitionen.
├── services // Gibt die Geschäftslogik an.
├── storage // Speicherung privater Schlüssel.
├── tasks // Handhabung von asynchronen Aufgaben und Hintergrundaufträgen.
└── tests
Die Website basiert auf einem Next.js-Boilerplate in TypeScript und verwendet Tailwind CSS für das Styling. React-i18next wird für die Internationalisierung genutzt.
[web/]
├── app // Layouts, Seiten und Komponenten
│ ├── (commonLayout) // gemeinsames Layout für die gesamte Anwendung
│ ├── (shareLayout) // Layouts, die speziell für tokenspezifische Sitzungen gemeinsam genutzt werden
│ ├── activate // Seite aufrufen
│ ├── components // gemeinsam genutzt von Seiten und Layouts
│ ├── install // Seite installieren
│ ├── signin // Anmeldeseite
│ └── styles // global geteilte Stile
├── assets // Statische Vermögenswerte
├── bin // Skripte, die beim Build-Schritt ausgeführt werden
├── config // einstellbare Einstellungen und Optionen
├── context // gemeinsame Kontexte, die von verschiedenen Teilen der Anwendung verwendet werden
├── dictionaries // Sprachspezifische Übersetzungsdateien
├── docker // Container-Konfigurationen
├── hooks // Wiederverwendbare Haken
├── i18n // Konfiguration der Internationalisierung
├── models // beschreibt Datenmodelle und Formen von API-Antworten
├── public // Meta-Assets wie Favicon
├── service // legt Formen von API-Aktionen fest
├── test
├── types // Beschreibungen von Funktionsparametern und Rückgabewerten
└── utils // Gemeinsame Nutzenfunktionen
Am Ende ist es Zeit, einen Pull Request (PR) in unserem Repository zu eröffnen. Für wesentliche Features mergen wir diese zunächst in den deploy/dev
-Branch zum Testen, bevor sie in den main
-Branch übernommen werden. Falls Sie auf Probleme wie Merge-Konflikte stoßen oder nicht wissen, wie man einen Pull Request erstellt, schauen Sie sich GitHub's Pull Request Tutorial an.
Und das war's! Sobald Ihr PR gemerged wurde, werden Sie als Mitwirkender in unserem README aufgeführt.
Wenn Sie beim Beitragen jemals nicht weiter wissen oder eine brennende Frage haben, richten Sie Ihre Anfrage einfach über das entsprechende GitHub-Issue an uns oder besuchen Sie unseren Discord für ein kurzes Gespräch.