Gibt es einen Paketmanager für Prolog?

9

Ich würde gerne wissen, was die besten Praktiken sind, um Prolog-Code / Bibliotheken mit anderen Programmierern (und mit sich selbst zwischen mehreren Projekten) zu teilen. Ich verwende SWI-Prolog selbst, bin aber auch daran interessiert, wie andere Prologs damit umgehen.

Zum Vergleich: Java hat Maven + JARs, Python hat EasyInstall + PythonEggs, und wahrscheinlich gibt es viele andere für andere Sprachen. Aber gibt es irgendwelche für Prolog?

SWI-Prolog-Pakete

In SWI-Prolog gibt es Packs, die vom Modul library(prolog_pack) unterstützt werden. Die Nachteile dieser sind:

  1. Sie müssen für jedes Paket entweder eine Archivdatei oder ein Git-Repository erstellen. Sagen wir, ich möchte 10 Packs erstellen. Jetzt muss ich 10 Git Repositories erstellen. Manchmal mache ich Änderungen, die sich auf mehrere Dateien auswirken, die möglicherweise in mehreren Paketen / Repos liegen, und verpflichte mich, mehrere Git-Repositories für eine einzelne (mehrere Dateien umfassende) Bearbeitung zu übernehmen.
  2. Um ein Paket zu erstellen, müssen Sie eine Handvoll Dateien auswählen, die zusammengehören. Manchmal finde ich heraus, dass eine Datei X sowohl zu Paket A als auch zu Paket B gehört. Jetzt muss ich Kopien der Datei X in den Repositories A und B verwalten oder ein weiteres Paket C erstellen, das nur aus X besteht und C importiert A und B.
  3. Packs werden auf einer öffentlichen Website veröffentlicht. Die meisten meiner Bibliotheken sind nur für mich interessant. Einige davon sind für bestimmte Personen interessant, mit denen ich zusammenarbeite, und nur wenige sind bereit für eine breitere / öffentliche Verbreitung.
  4. Der Paketverwalter muss Interpack-Abhängigkeiten angeben. Für komplizierte Hierarchien von Bibliotheken, die mir wie unnötige Arbeit erscheinen. Ich verwende Prolog-Module bereits sehr stringent und möchte einfach die Hierarchie der Prolog-Modulimporte als Abhängigkeitsdiagramm verwenden.

Git Submodul

Ein anderer Ansatz, den ich bis jetzt benutzt habe, sind Git Submodule. Abhängigkeiten zwischen Bibliotheken werden erreicht, indem ein Repository in ein anderes importiert wird. Dies hat einige der gleichen Nachteile wie SWI-Prolog-Pakete:

  1. Ein Git-Repository für jede Bibliothek und damit viele zu pflegende Repositories.
  2. Der Betreuer muss die Dateien per Repro weise auswählen und angeben, welche Git-Submoduleinschlüsse benötigt werden.
  3. Das Aktualisieren vorhandener Bibliotheken ist sehr schwierig. Ich habe (auf die harte Tour) herausgefunden, dass die meisten Leute, denen ich meinen Code übergebe, nicht in der Lage sind, ein Git-Repository mit vielen interdependenten Submodul-Importen erfolgreich zu aktualisieren. (Ich habe den größten Respekt vor dem gelegentlichen Git-Guru, der Submodule benutzt und es immer richtig macht, aber die meisten Nicht-Programmierer und einige Programmierer, mit denen ich arbeite, finden es zu schwierig.)

Mein idealer Ansatz

Meine persönlichen Vorlieben für eine perfekte Code-Sharing-Methode von Prolog wären:

  1. Die Anzahl der Bibliotheken, die Sie verbreiten, und die Anzahl der Git-Repositories, die Sie haben, sind unabhängig. Insbesondere kann ich ein umfangreiches Repository haben, von dem Teile auf verschiedene Arten verbreitet werden. Wenn jemand mein Prolog-Modul gerne mit DCG-Helfer-Prädikaten (wieder) verwenden möchte, kann ich diese einzelne Datei (plus mögliche Abhängigkeiten) einfach an diese Person weitergeben.
  2. Sie müssen nicht einzelne Dateien manuell auswählen und manuell kopieren, sondern Sie lassen einen Algorithmus die Hierarchie der Modulimporte durchlaufen, um diejenigen Dateien zu extrahieren, die (scheinbar) zusammengehören. Die Dateien werden heruntergeladen, wenn das Programm zum ersten Mal ausgeführt wird. Die Dateien können alle zum selben Git Repository gehören oder zu mehreren, der Algorithmus sollte sich überhaupt nicht um die Zuordnung zwischen Repositories und Bibliotheken oder zwischen Repositories und Dateien kümmern.
  3. Der Betreuer des Codes kann entscheiden, ob eine Bibliothek öffentlich oder für eine begrenzte Gruppe von Personen veröffentlicht wird (oder für die begrenzte Gruppe, die nur den Betreuer enthält).
  4. Die Hierarchie der Modulimporte zwischen den Dateien reicht aus, um die Abhängigkeit zu verfolgen.

Dies bedeutet, dass mein Ansatz der idealen Bibliotheksnutzung dateibasiert und nicht paketbasiert ist. Wenn das Prolog-Modul A das Prolog-Modul B verwendet und A geladen ist, wird B entweder aus einer lokalen Datei geladen (falls vorhanden) oder von einem Repository heruntergeladen. Ich bin mir nicht sicher, wie üblich ein dateibasierter Ansatz in anderen Sprachen ist. Die oben genannten Maven + JARs und EasyInstall + PythonEggs sind beide paketbasiert.

Ich bin sehr daran interessiert, was andere Prolog-Programmierer verwenden und über dieses Thema nachdenken!

    
Wouter Beek 08.04.2014, 19:11
quelle

2 Antworten

2

Ich schätze, ein solcher einfacher Traversal-Algorithmus kann Ihnen helfen eine Sammlung von Modulen, wenn Sie bereits kommentiert haben jene Module, die zu einem Paket gehören und diese Module welche noch nicht zu einem Paket gehören. Es wird nachgeben eine Teilmenge der Module, die noch nicht zu einer gehören Paket.

Aber ich habe das Gefühl, dass dies den Punkt verfehlt. ich denke, Software-Engineering für Pakete hat eine andere Ziel als nur ein Paket zu liefern. Normalerweise eins ist mit mehreren Paketen und diesen Paketen konfrontiert kann Abhängigkeiten haben, die in der Abhängigkeit wurzeln der Module selbst.

Mathematisch:

%Vor%

Wenn ich also Modulabhängigkeiten habe, kann ich ableiten Paketabhängigkeiten von ihm:

%Vor%

Ihr Algorithmus könnte dann ein Paket p ableiten könnte von einigen Paketen p1, .., pm abhängen, die haben wurde bereits verwendet, um die vorhandenen Module zu kommentieren. Aber Software Engineering hat viele Wege gefunden Identifizieren Sie mehrere Pakete, typische Architekturen sind vertikale Schichtung, horizontale Schichtung, etc .. Vielleicht gibt es auch Algorithmen dafür.

Aber die Dinge sind nicht so einfach. Pakete sind normalerweise definiert, um in der Co-Evolution von Modulen und zu helfen um das Change Management und Release Management zu erleichtern. Wenn Module mitentwickelt werden, möchte man keines freigeben Modul nach dem anderen. Man möchte eine Menge veröffentlichen Module, die die gleiche Evolutionsstufe erreicht hat, so dass dieser Satz von Modulen fruchtbar interagieren kann.

Aber wenn wir Module entwickeln, werden wir auch habe Evolution von Paketen. Und diese Evolution wird passieren, wenn Sie ein einzelnes Paket haben oder wenn Sie gehen mehr mit den vielen Paketen für deine Sachen. Und ich Ich bin mir nicht sicher, ob die bestehenden Paketsysteme für Prologs helfen hier schon. Was ich für SWI-Prolog sehe ist zum Beispiel eine Versionierung von Paketen und ein Todo Liste für Pakete:
Ссылка

Die oben genannten Dinge machen Sinn. Aber sie nicht direkt Paketabhängigkeit und deren Evolution. In Jekejeke Prolog bin ich momentan Experimentieren bei der Verbesserung der Modulabhängigkeit. Die Idee ist zum Beispiel, dass der Endnutzer es kann Laden Sie ein Modul clpfd über den folgenden Befehl:

%Vor%

Wenn ein Paket installiert und aktiviert ist, das hat ein Modul clpfd der Befehl wird erfolgreich sein. Und wenn Kein solches Paket ist installiert oder ein Paket ist installiert und noch nicht aktiviert, wird der Befehl fehlschlagen. Das Home-Paket bzw. das Modul clpfd verwenden wird andere Module und somit Pakete. Wenn es verwendet wird ein Modul lokal zu seinem eigenen Paket kann es tun so wie folgt, keine Notwendigkeit für die Bibliothek / 1:

%Vor%

Aber wenn es ein Modul verwendet, das nicht lokal ist ein eigenes Paket macht es typischerweise anders. Zum Beispiel könnte ein Modul clpfd ein Modul verwenden sich bewerben. Und es wird so mit Bibliothek / 1:

%Vor%

Und jetzt erkennen wir, dass wir es nicht wissen werden durch inspizieren des clpfd- oder helpermoduls wann es tut das oben von wo es das nehmen wird Modul anwenden. Wir kennen nur die Paketabhängigkeit wenn wir einen bestimmten Satz von Paketen haben Hand und wenn wir den Modulnamen auflösen gelten zu seinem Paket.

Diese Flexibilität hat ihre Vor- und Nachteile. Die Nachteile sind, dass wir kein festes Paket erstellen können Abhängigkeiten. Und diese Tools für die Versionierung usw., die auf festen Paketabhängigkeiten beruhen wird nicht funktionieren. Also wäre eine Lösung Bootstrap Versionierung für Pakete von Versionierung für Module, Ähnlich wie wir Abhängigkeiten zwischen Paketen ableiten aus Abhängigkeiten von Modulen.

Aber ich bin mir noch nicht sicher, wie das funktionieren würde. Das Komplexität kann sicherlich reduziert werden, wenn wir unterscheiden können zwischen öffentlichen und privaten Modulen. Beispielsweise der obige Modulhelfer könnte allein verwendet werden durch clpfd, und kann bei der Bestimmung weggelassen werden Paketabhängigkeiten und Paketversionierung.

Meine bisherigen Ideen:

  • Leiten Sie Paketabhängigkeiten von Modulen
  • ab
  • Leiten Sie die Paketversionierung von Modulen
  • ab
  • Erlaube private und öffentliche Module in Paketen.

Tschüss

    
j4n bur53 09.04.2014, 12:58
quelle
2

Über Swi-Prolog-Pakete:

  1. Ich sehe ein Paket als eine Sammlung von Prolog-Modulen. Ein einzelnes Modul sollte nur zu einem einzigen Paket gehören, nicht zu den Paketen A und B.
  2. Wenn Datei X in Paket A und Paket B gehören soll, sollte sie eigentlich in Paket C gehören, das sowohl von A als auch von B abhängig ist.
  3. Sie können jetzt bereits private Pakete haben, müssen Sie aber sehr vorsichtig sein, um sie nicht automatisch während der Installation zu veröffentlichen. Dies muss in der Tat verbessert werden. Patches willkommen:)
  4. Ich sehe explizite Abhängigkeiten als einzige vernünftige Lösung. Es gibt bereits 1 in pack.pl. Braucht etwas Arbeit, um den Versionsbereich anzugeben.

Imho, das größte Problem mit der aktuellen Packspezifikation / Implementierung ist, dass es keine semantische Versionierung erfordert. Einige Pakete geben explizit an, dass sie es verwenden, andere verwenden es, weisen jedoch nicht darauf hin. Eine semantische Versionierung würde, wenn sie von den Paketbetreuern respektiert wird, die Erkennung / Auflösung von Versionskonflikten erheblich vereinfachen. Das andere Problem ist, dass Swi-Packs gut für Swi sind und andere Prologs in der Kälte lassen.

Ich wünschte, die Packspezifikation / Implementierung wurde so einfach und magisch wie möglich gehalten. Es gibt genug von Prolog "AI this" und "AI that" bereits. Ein alternativer Paketmanager könnte darüber hinaus implementiert werden und als Paket veröffentlicht werden :).

    
Raivo Laanemets 12.04.2014 12:41
quelle