Gibt es einen Paketmanager für Prolog?

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:

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

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:

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:

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:

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

Ü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 :).