Neuer OpenSource Package Manager

[mkinzler]

https://github.com/Memnarch/Delphinus
https://github.com/Memnarch/Delphinu...ling-Delphinus

[BUG]

Schönes Projekt, wurde sich hier ja schon oft gewünscht. Ich vermute mal leise, das ist der Memnarch aus der DP :stupid:

Es wäre imho günstig, eine kurze Beschreibung und zumindest einen Link auf die Installationsanleitung in der readme.md unterzubringen:

Zitat:

Zitat von Wiki/Home

Delphinus is a new Packagemanager which works from within your IDE to install new stuff, like packages and components. It's compatibility target is XE and up. Developer can publish their packages for Delphinus without notifying me, by simply following the steps on Publishing your Project for Delphinus

Wen ich sonst auf so einer Projektseite lande, muss ich schon sehr interessiert oder gelangweilt sein, um mir das näher anzugucken.

[Memnarch]

Zitat:

Zitat von BUG (Beitrag 1313149)

Ich vermute mal leise, das ist der Memnarch aus der DP :stupid:

Wie hab ich mich nur verraten :stupid:

Zitat:

Zitat von BUG (Beitrag 1313149)

Es wäre imho günstig, eine kurze Beschreibung und zumindest einen Link auf die Installationsanleitung in der readme.md unterzubringen:

Gute Idee

Zitat:

Zitat von BUG (Beitrag 1313149)

Wen ich sonst auf so einer Projektseite lande, muss ich schon sehr interessiert oder gelangweilt sein, um mir das näher anzugucken.

Immer her mit Tips, Anregungen und Kritik. Jede Hilfe ist willkommen :)

EDIT: Kurze Readme hinzugefügt, fürs gröbste :)

[mkinzler]

Da bin ich mal gespannt, ob sich Dein Repository schnell füllt. Besser wäre es natürlich wenn EMBT die, aus meiner Sicht übertriebenen Beschränkungen von GetiT aufheben würde und man dann alles aus einer Quelle beziehen könnte.

[mquadrat]

Das Problem bei GetIt ist halt, dass EMBT den Community-Gedanken, da nur halbherzig umsetzt. Man möchte eher ein AppStore sein, als ein Package Manager.

@Thema

Hilfreich wäre sicher ein Best-Practices für die Packages. Gerade was das Bestimmen der Compiler-Versionen angeht. Oder eben ein Video-Tutorial oder so. Aber das kann ja jemand anders machen. Bei mir sieht es zeitlich im Moment eher schlecht aus leider :/

[Uwe Raabe]

Zitat:

Zitat von mquadrat (Beitrag 1313179)

Man möchte eher ein AppStore sein, als ein Package Manager.

Eine diesbezügliche Frage ist ja auch regelmäßiger Bestandteil der Developer Survey.

In XE8 ist das ja auch schon ansatzweise umgesetzt - siehe BeaconFence, das eine entsprechende Lizenz voraussetzt. Vielleicht sehen wir demnächst noch andere Produkte in GetIt, wie z.B. die neu erworbenen CodeSite und Konopka Signature VCL Controls (ich schlage das Kürzel KSVC vor).

@Alexander, vielleicht solltest du dich mit Roman Kassebaum in Verbindung setzen. Er pflegt die TurpoPack-Komponenten in GetIt, die auch allesamt auf GitHub vorliegen. Das wären immerhin auf einen Schlag zehn Einträge.

[Daniel]

Lässt sich der Katalog des Managers automatisiert auslesen und ist das überhaupt gewünscht?
Ich denke da an die Option, den Inhalt hier anzuzeigen und durchsuchbar zu machen - selbstverständlich nur in Abstimmung mit Alex.

[Uwe Raabe]

Zitat:

Zitat von Daniel (Beitrag 1313185)

Lässt sich der Katalog des Managers automatisiert auslesen und ist das überhaupt gewünscht?
Ich denke da an die Option, den Inhalt hier anzuzeigen und durchsuchbar zu machen - selbstverständlich nur in Abstimmung mit Alex.

Wenn ich die Sourcen richtig interpretiere, wird zur Erstellung des Katalogs eine Suchanfrage an die GitHub-API gestellt:

Delphi-Quellcode:

  CGitRepoSearch = 'https://api.github.com/search/repositories?q="Delphinus-Support"+in:readme&per_page=100';

[mkinzler]

Es scheint eine Funktionalität von GitHub verwendet zu werden. Es wird nach den in den Repositories hinterlegten Stichwörtern gesucht ( in diesem Fall "Delphinus-Support").

Siehe DN.PackageProvider.GitHub.pas

[Sir Rufo]

Steht ja auch so bei den Requirements im Wiki
https://github.com/Memnarch/Delphinu...-for-Delphinus
;)

Und den Such-Link kann man auch direkt im Browser abfragen (aber die JSON-Lesebrille nicht vergessen)
https://api.github.com/search/reposi...e&per_page=100

[Memnarch]

Zitat:

Zitat von Daniel (Beitrag 1313185)

Lässt sich der Katalog des Managers automatisiert auslesen und ist das überhaupt gewünscht?
Ich denke da an die Option, den Inhalt hier anzuzeigen und durchsuchbar zu machen - selbstverständlich nur in Abstimmung mit Alex.

OH GERNE! :)
Ist ja schließlich auch support für mein Projekt^^.

PS: @Daniel theoretisch könnte es bei der suchanfrage auch False positives geben. Es muss theoretisch auch noch geguckt werden, ob da überhaupt ne Info.Json im Repo ist. Der Sanity-Check wird bei mir auch noch nicht so ganz umgesetzt, wäre aber zubeachten wens mal proper wird^^.

Mormot ist übrigens schon im Repo. Und gleich mal feststellen müssen, dass DelphiXE sich an Tabs verschluckt und einige der funktionen von delphi nicht funktionieren, wenn da sowas steht wie:

C:\Ornder\.\OrdnerB

Das bedarf nochmal pflege heute abend^^

[mkinzler]

Bei Delphi XE8 kommt nun dieser Fehler

[Memnarch]

Jep da hab ich schon was in verdacht. Hatte ich hier gerade auch unter XE. Da hat der TDNInstalledPackageProvider im Comps verzeichnis versucht was zu laden was nicht ganz sauber war, wie mir scheint. Da muss ich nochmal gucken.

[mkinzler]

Gibt es Platzhalter für die Compilerversion für die Packages?

[Memnarch]

Was meinst du mit Platzhaltern?
(Also soetwas wie XE-XE2, XE4-XE5, also support mit lücken?)

[Uwe Raabe]

Zitat:

Zitat von Memnarch (Beitrag 1313216)

Was meinst du mit Platzhaltern?
(Also soetwas wie XE-XE2, XE4-XE5, also support mit lücken?)

Ich weiß nicht, ob Markus das meint, aber wenn ich das richtig sehe, muss ich, wenn ich für jede Delphi-Version eine eigene Projektgruppe (in einem eigenen Verzeichnis) habe, für eben jede Delphi-Version einen eigenen Eintrag unter projects machen, jeweils mit der passende platforms-Einschränkung. Da würde ich mir eine Art Platzhalter wünschen, damit ich z.B. sowas schreiben kann:

Code:

"projects":
    [
        {
            "project": "Packages\\Delphi$(DelphiDisplayName)\\Spring4D.Groupproj"
        }
    ]

Je nach Delphi-Version würde dann $(DelphiDisplayName) in XE..XE8 aufgelöst werden, wobei man sich dann auf eine einheitliche Nomenklatur für die Delphi-Versionen festlegen müsste.

[Memnarch]

Ah okay,
Nein soetwas gibt es aktuell noch nicht. Ich wollte das ganze erstmal so einfach wie möglich halten, wobei ich es verstehen kann, dass man den schreibkram reduzieren möchte. Allerdings gilt dies normalerweise nur für das erste Setup, weswegen ich das persönlich aktuell nicht ganz so kritisch sehe.

[mkinzler]

Der DP fork von "The-new-Drag-and-Drop-Component-Suite-for-Delphi" ( von Sven Harazim/sh17) ist nun verfügbar.

[Memnarch]

Mh das taucht per suche gerade aber nicht auf o.O
PS: wenn das Projekt auch auf Github als Fork markiert ist wird es (spätestens in Zukunft) defaultmässig nicht angezeigt, um Forkflooding zu vermeiden.
PSS: jub is nen fork, nein wird defaultmässig bei der suche nicht angezeigt. ihr müsst leider das Original-Repo anpassen.

[mkinzler]

Ich habe es testweise lokal installiert, die Suche auf GitHUB funktioniert ja leider nicht (Jpeg-Fehler)

https://github.com/DelphiPraxis/The-...ite-for-Delphi

[Memnarch]

Hatte mir das ganze schon so angeguckt. Habe die Wiki auf der HowToPublish-Seite korrigiert. Forks werden aus obigen Gründen nicht angezeigt(später vllt nen haken aber das Flooded die resultate irgendwann wie blöde).

Lässt sich ja zum Glück auch im Browser testen, etwas:

Zitat:

https://api.github.com/search/reposi...e&per_page=100

[sh17]

also ich würde das Hauptprojekt von der Drag&Drop-Komponente auch von landrix zur DelphiPraxis umziehen und das derzeitige Original löschen (wenn das möglich ist), bräuchte dann nur dort Schreibrechte

[Memnarch]

Das wäre natürlich auch eine Möglichkeit. Hauptsache das FORK-Flag verschwindet ;)

[mkinzler]

Die hast Du nun.

[sh17]

Zitat:

Zitat von mkinzler (Beitrag 1313246)

Die hast Du nun.

OK, Danke, jetzt muss ich mal schauen, wie das funktioniert. Es sei denn, jemand hat schnell ne Info. Hab erstmal die Änderungen aktualisiert.

[sh17]

Einfach löschen?

https://help.github.com/articles/wha...es-visibility/

[mkinzler]

Das Projekt ist schon mal sichtbar ;)

[sh17]

ich glaub das war nicht gut, bitte per Threema weiter Markus

[Sir Rufo]

Zitat:

Zitat von Memnarch (Beitrag 1313244)

Das wäre natürlich auch eine Möglichkeit. Hauptsache das FORK-Flag verschwindet ;)

Das muss aber gar nicht weg ...
https://api.github.com/search/reposi...l&per_page=100

Code:

https://api.github.com/search/repositories?
q=%22Delphinus-Support%22
+in:readme
+fork:true
+language:pascal
&per_page=100

[Memnarch]

ja aber dann sieht man alle forks. Mein AsciiImage wurde bereits mehrfach geforked. Wenn da jetzt jemand seinen Fork auf die aktuelle version schiebt, würde meine Componente X-Mal auftauchen. Selbiges gilt für andere Projekte. Anscheinend Forken viele User sobald sie an einem Projekt interessiert sind. Könnte ja plötzlich verschwinden :(

[Sir Rufo]

Nimm doch so eine kleine CheckBox (Forks anzeigen) oder eine ComboBox ("ohne/mit/nur" Forks) ;)

[BUG]

Zitat:

Zitat von Memnarch (Beitrag 1313255)

Könnte ja plötzlich verschwinden :(

Die Sorge ist ja berechtigt.

Vielleicht solltest du in dein Manifest eine Original-Quell-URL (oder mehrere, mit Reihenfolge*) hinterlegen und die Packages danach zu gewichten. Dann kannst du "gleiche" Packages zusammenfassen und das originalste als Default nehmen.
* Quasi eine Mirror-URL. Ich finde die Möglichkeit nicht schlecht, nicht-Package-Repositories zu forken und mit einem Manifest zu versehen, das auch auf das Original-Repository verweist ... falls dieses irgendwann auch ein Manifest bekommt.

[Memnarch]

Jaa und jetzt erreichen wir nen bisschen Dependency-Hell(also die idee find ich prinzipiel nicht schlecht. Muss ich mir noch was überlegen):

ComponentA wurde geforkt, und als Package veröffentlicht.
ComponentA(Original) wird jetzt auch als Package veröffentlicht.

Jetzt ist es SEHR wahrscheinlich, dass beide unter verschiedenen IDs laufen. Beim späteren implementieren für Dependencies wird das irgendwann ne super quelle für Verwirrungen.
(Spätestens bei den Endusern)Aktuell möchte ich halt mitunter sicherstellen, dass die eigentlichen Authoren der Components diese ins Delphinus packen, und nicht irgendwer. Ja in diesem fall hat es leider einen Nachteil, auf die breite Masse gesehen finde ich es aktuell so besser.

Ja ich kann es verstehen, allerdings geht dann irgendwo komplett jedwede kontrolle verloren.

[sh17]

Also per Default wäre ich auch für die Original-Quelle, das merke ich momentan bei richtig beliebten Projekten, find da mal das Original, wenn alle aktiv sind.

Das Problem kommt dann, wenn nur noch die Forks aktiv sind und das Original tot

[Memnarch]

Zitat:

Zitat von sh17 (Beitrag 1313265)

Das Problem kommt dann, wenn nur noch die Forks aktiv sind und das Original tot

Das kann ich verstehen. Und ist auch hier aktuell erstmal ein Problem. Ich hoffe nur dass es erstmal nicht so schnell auftritt. Wenn das projekt ohne weiteres ausstirbt ist sowieso noch ein anderes Problem präsent: Das Package bleibt im System. Das Projekt müsste also eigentlich sauber an jemand anderen übergeben werden. (Eigentlich!)

[Memnarch]

@sh17 ihr habt euch übrigens gerade selbst als Dependency eingetragen! Den eintrag müsst ihr entfernen ;)

[mkinzler]

The-Drag-and-Drop-Component-Suite-for-Delphi.
ist nun das Hauptrepository und sollte gesehen werden.

[Memnarch]

und ihr habts json kaputt gemacht, da ist ne ] übrig geblieben ;)

[mkinzler]

Habe ich schon korrigiert

[Memnarch]

Und ihr habt vergessen für XE das Package einzutragen^^

Ich glaub ich schreib irgendwann nochmal nen kleines validierungstool als Hilfe, damit man soetwas leichter sieht^^

EDIT: für die Install.json gibt es neben compiler_min/_max auch einfach nur compiler, wen mann nur eine einzige version targeten möchte ;)