Neuer OpenSource Package Manager

[sh17]

Ich merk schon, ich muss da nix mehr machen :) Danke

Zitat:

Zitat von mkinzler (Beitrag 1314130)

Zitat:

Dein Wort in Gottes Ohr

Ich hatte es natürlich nach Anpassung der Drag'n'Drop Komponenten getestet.

[mkinzler]

Zitat:

Zitat von sh17 (Beitrag 1314132)

Ich merk schon, ich muss da nix mehr machen :) Danke

Zitat:

Zitat von mkinzler (Beitrag 1314130)

Zitat:

Dein Wort in Gottes Ohr

Ich hatte es natürlich nach Anpassung der Drag'n'Drop Komponenten getestet.

In diesem Fall musste man ausser dem Anlegen der neuen Packages und Anpassen der Delphinus.Install.json nichts machen.

[sh17]

Trotzdem Danke :cheers:

[sh17]

So, jetzt kommts Dicke @Memnarch.

Erst mal vielen Dank für Deinen Einsatz in deinen package manager. Die Richtung passt und wird hoffentlich eine ernstzunehmende Alternative zu GetIt, ABER:

In meinem Fall nützt mir der Manager nichts, weil er die Komponenten im globalen IDE-Package-Pfad installiert.

Bei uns sind die Komponenten aber direkt im Repository integriert, d.h. wenn ich eine ältere Version auschecke, hab ich auch die alten Komponenten in der IDE.

Wäre es möglich, das ganze so umzubauen, das es pro Projektgruppe/Verzeichnis funktioniert? Eigentlich wie schon bei NuGet in MSVS, da werden die packages auch pro Projekt verwaltet.
Und noch eine Stufe weiter wäre auch eine Unterstützung für Libs denkbar, die nicht kompiliert werden müssen und nur im Quelltext zum Projekt hinzugefügt werden.

Wäre das eine Entwicklung, die weiter verfolgt werden sollte? Aus Deiner Sicht?

[mkinzler]

Zitat:

Und noch eine Stufe weiter wäre auch eine Unterstützung für Libs denkbar, die nicht kompiliert werden müssen und nur im Quelltext zum Projekt hinzugefügt werden.

Das sollte schon jetzt funktionieren, da die angegebenen Verzeichnisse ja zuerst in den Zielpfad kopiert werden.

Wir können das Projekt ja Forken, um es entsprechend zu erweitern.

[Memnarch]

Zitat:

Zitat von sh17 (Beitrag 1314224)

So, jetzt kommts Dicke @Memnarch.

Erst mal vielen Dank für Deinen Einsatz in deinen package manager. Die Richtung passt und wird hoffentlich eine ernstzunehmende Alternative zu GetIt, ABER:

In meinem Fall nützt mir der Manager nichts, weil er die Komponenten im globalen IDE-Package-Pfad installiert.

Bei uns sind die Komponenten aber direkt im Repository integriert, d.h. wenn ich eine ältere Version auschecke, hab ich auch die alten Komponenten in der IDE.

Wäre es möglich, das ganze so umzubauen, das es pro Projektgruppe/Verzeichnis funktioniert? Eigentlich wie schon bei NuGet in MSVS, da werden die packages auch pro Projekt verwaltet.
Und noch eine Stufe weiter wäre auch eine Unterstützung für Libs denkbar, die nicht kompiliert werden müssen und nur im Quelltext zum Projekt hinzugefügt werden.

Wäre das eine Entwicklung, die weiter verfolgt werden sollte? Aus Deiner Sicht?

Hi,
Die Componennten pro projekt zu installieren, wurde schon an anderer stelle gewünscht und ich werde dies durchaus als Ziel für die Zukunft notieren. Das theoretische Prinzip sollt auch nicht zu schwer umzusetzen sein(dank den Abstraktionen lässt sich jede input/output ebene eigentlich gut steuern). Es müsste ein unterverzeichnis für das Projekt angelegt werden, dort alle Componennten installiert werden und die Suchpfade in der Projektdatei eingetragen werden.(Referenzen in der DProj selbst sind dann natürlich pflicht, besser als ne datei daneben)

Zitat:

Zitat von mkinzler (Beitrag 1314227)

Zitat:

Und noch eine Stufe weiter wäre auch eine Unterstützung für Libs denkbar, die nicht kompiliert werden müssen und nur im Quelltext zum Projekt hinzugefügt werden.

Das sollte schon jetzt funktionieren, da die angegebenen Verzeichnisse ja zuerst in den Zielpfad kopiert werden.

Siehe Mormot ;)

Zitat:

Zitat von mkinzler (Beitrag 1314227)

Wir können das Projekt ja Forken, um es entsprechend zu erweitern.

Ich bin prinzipiel für jede Hilfe Dankbar, nur möchte ich darauf hinweisen, dass ich um jeden Preis eine Linuxifizierung vermeiden würde wenns geht. also zum Beitragen immer gern :).
Allerdings wäre es nicht besser, wen man sich dann zur gegebener Zeit erstmal zusammensetzt um den Featurerahmen bzw wie das ganze implementiert werden soll, abzusteken? Ich plahne z.B. auch noch die implementierung von Dependencies. Das zusammen mit Global/Project-Based installations wird ne schöne Hölle(die ich aber bereit bin zu betreten).

Möchte es vermeiden, dass wir uns dann behaken :)

EDIT: was auch geplahnt war, und das könnte ein Teil des per Projektinstallationsproblems lösen:
Componennten werden immer "Global" installiert werden. Es können aber von einer komponennte mehrere Versionen installiert sein, und nur eine ist aktiv. (Welche version benötigt wird, ließe sich dann in einem Projekt abspeichern). Wobei per projekt immernoch seine Vorteile hat.

[Uwe Raabe]

Zitat:

Zitat von Memnarch (Beitrag 1314231)

Die Componennten pro projekt zu installieren, wurde schon an anderer stelle gewünscht und ich werde dies durchaus als Ziel für die Zukunft notieren.

Bei "per Projekt" muss man aufpassen. Ist vielleicht nur theoretisch, aber es hindert dich niemand daran, bei einem geöffneten Projekt ein projektfremdes Form zu öffnen. Wenn dieses dann aber zu einem Projekt gehört, das eine andere Bibliotheksversion verwendet, können sich die Werte in der DFM entsprechend ändern und das Form wirft eine Fehlermeldung beim nächsten Laden, weil die Anwendung mit der anderen Bibliotheksversion compiliert wird.

[Memnarch]

Zitat:

Zitat von Uwe Raabe (Beitrag 1314260)

Zitat:

Zitat von Memnarch (Beitrag 1314231)

Die Componennten pro projekt zu installieren, wurde schon an anderer stelle gewünscht und ich werde dies durchaus als Ziel für die Zukunft notieren.

Bei "per Projekt" muss man aufpassen. Ist vielleicht nur theoretisch, aber es hindert dich niemand daran, bei einem geöffneten Projekt ein projektfremdes Form zu öffnen. Wenn dieses dann aber zu einem Projekt gehört, das eine andere Bibliotheksversion verwendet, können sich die Werte in der DFM entsprechend ändern und das Form wirft eine Fehlermeldung beim nächsten Laden, weil die Anwendung mit der anderen Bibliotheksversion compiliert wird.

Das rangiert dann unter Blöd gelaufen!
Was mir vorschwebt:
Die componennten werden alle global installiert. Von einer componennte können mehrere versionen lokal vorhanden sein, es ist aber immer nur eine Aktiv. Projekte können dann mit Paketen und bestimmten versionen gelinkt werden. Die IDE stellt sich dann entsprechend um, wenn so ein Projekt geöffnet wird. Bei gruppenprojekten gibt es dann z.B. einen Dialog, der darauf aufmerksam macht, das 2 Projekte PaketA in version X und Y haben wollen, und was passieren soll.

Das ganze muss etwas anders ablaufen als in NuGet, da es in Delphi(behaupte ich mal pauschal) öfter der fall ist, Designtime-Komponennten zu vertreiben. Bzw Bibliotheken die sowohl aus Runtime als auch Designtime komponennten bestehen. Und würde den Mechanismus deswegen pauschal einfach halten. (In der Hoffnung trotzdem den großteil abdecken zu können).

Außerdem schleppt man wenn man es wie in NuGet macht pro projekt jeden kram einer Componennte mit sich rum(auch die Demos und was man sonst so nicht braucht).

[mkinzler]

Zitat:

Das ganze muss etwas anders ablaufen, da es in Delphi(behaupte ich mal pauschal) öfter der fall ist, Designtime-Komponennten zu vertreiben.

Seit der Einführung des 64Bit Compilers, OSX und dem Mobile Studio gibt es eigentlich genügend Anreize 2 getrennte Packages zu erstellen.

[Memnarch]

Ja die Packages sind getrennt, aber ein Delphinus-Package hat nunmal alles und ich müsste das entsprechend sizieren o.O. Deswegen macht es Sinn, dass die Dateien aller packages und Versionen selbst alle in einem globalen "cache" sind, und die IDE dann praktisch switched.

[sh17]

ich würde sogar soweit gehen, Komponenten ohne Design- und Runtime-package nicht zuzulassen.

[Memnarch]

Zitat:

Zitat von sh17 (Beitrag 1314270)

ich würde sogar soweit gehen, Komponenten ohne Design- und Runtime-package nicht zuzulassen.

Es ist kein verbrechen nur Source zu verteilen. Es macht Sinn RuntimePackages anzubieten, aber ich finde nicht, dass es pflicht sein muss. Und in der zukunft werde ich nen einfachen mechanismus bauen um zu versuchen die beigelegten pas dateien nach DCU vorzukompilieren. also auch hier kein Beinbruch, was die IDE-Kompilierzeit angeht.

[mkinzler]

Diese können dann nur Win32 unterstützen, kein 64Bit, kein OSX, kein iOS, kein Android, (kein Linux: ab Delphi 10 Buxtehude), ...

[Memnarch]

Zitat:

Zitat von mkinzler (Beitrag 1314275)

Diese können dann nur Win32 unterstützen, kein 64Bit, kein OSX, kein iOS, kein Android, (kein Linux: ab Delphi 10 Buxtehude), ...

Wieso den dass o.O?

[mkinzler]

Da die IDE Win32 ist. Gibt es kein getrenntes Laufzeitpackage ist dies dann auch nur für Win32 verfügbar.

[Memnarch]

Die Units lassen sich doch trotzdem vorkompilieren? dproj generieren, units rein, msbuild drauf.

[Memnarch]

Wer will kann übrigens nen paar Vorschläge für "Common"-Tags machen. Im Branch Feature-UI bastel ich gerade an der Oberfläche rum, und neben einer Suche wird es selbstverständlich eine Tag(s) property für die Info geben. In der Oberfläche wird man sich dann TagFilter anlegen könenn um sich praktisch eigene Gruppen zu erstellen. (Die Tagfilter können dann Wahlweise auf die Liste von Online-Packages, Installierten-Packages oder Packages mit Updates angewand werden).

Die Tags sollten immer Singular sein und so abstrakt wie möglich(und so kurz wie möglich :P). Mir schwebt da sowas vor wie:

• VCL (Enthält VCL kram)
• FMX (Enthält FMX kram)
• Design (Enthält Designcomponennten)
• IDE-Extension
• Demo

Die Common-Tags werden dann als Leitfaden in der Wiki aufgeführt.

[Der schöne Günther]

Ich habe es grade einmal zum ersten mal kurz ausprobiert.

Sieht wirklich sehr schön aus. Wenn es erlaubt ist: Ich habe drei kleine Kritikpunkte an der Oberfläche:

- Bitte den Optionen-Dialog mit ESC schließbar machen
- Wenn die Einträge schon so gute Bilder haben: Wäre dann nicht auch ein Beschreibungstext möglich? Wenn keiner angegeben ist dann vielleicht den Github-Titelseitentext nehmen?
- Statt dem "Haus"-Button wäre mir ein klassischer, blauer Link zum Draufklicken. Ich fühle mich wohler wenn ich direkt die URL sehe und keine mysteriöse Tür ;-)


Auch Daumen hoch für ein funktionierendes Github-Wiki. :thumb: Bei wie vielen Projekten muss man sich durch irgendwelche lokalen Dateien wühlen um überhaupt herauszufinden wie man es installiert? Hier kann man direkt nachsehen. Toll.

[Memnarch]

Ich entstaub hier mal :D
http://memnarch.bplaced.net/blog/201...aries-anymore/

@Günther:
Der Beschreibungstext muss im Repository angegeben sein. Das entscheiden die Ersteller. Wobei ich zugeben muss, dass der Beschreibungstext in der alten UI etwas versteckt war ;)

[mjustin]

Zu den Requirements für die Delphinus Integration hätte ich da mal eine Frage:

Zitat:

add an Delphinus.Info.json to the repository root
add an Delphinus.Install.json to the repository root
add at least one version (optional) see: Versioning your package
add "Delphinus-Support" (without quotes) to your readme within your repository

Könnte man es auch so einrichten, dass alle Delphinus Dateien in einem getrennten Branch (d.h. nicht im MASTER) liegen können?
So wäre das root Verzeichnis etwas aufgeräumter. Das wäre dann so wie bei den Github-Pages (https://pages.github.com/) gelöst, die auch nicht im Master sondern in einem eigenen Branch des Projekts liegen.

Im Root lägen dann nur das Readme, die gitignore und die Lizenz Datei.

Aus Sicht eines erstmaligen "Besuchers" des Projekts würde kein "Oh, Delphinus, kenne ich nicht, muss man das haben um mit dem Projekt zu arbeiten?"-Effekt entstehen.

(Allerdings könnte man durchaus auch andersrum argumentieren: je mehr Dateien im Repo, desto beeindruckender ;)

[Memnarch]

Diesbezüglich habe ich bisher keine Notwendigkeit gesehen. Zumal es das ganze von meinerseite unnötige aufblähen würde(mitunter mehr calls auf die api). Andere Packagesysteme wie das für ATom (Github Editor) erwarten die Dateien dort auch (iirc).

Und pages.github.io braucht nen extra repository. Die einzelnen Pages/Whatever mögen dann in Branches sein ;)

[mquadrat]

Bei Composer müssen sie da auch liegen. Macht ja auch Sinn die Definitionen für die Package-Manager im Root des Package zu haben.

Viel spannender für mich wären die Abhängigkeiten. Viele Projekte haben ja inzwischen mehrere trennbare Komponenten (z.B. Spring4D oder mORMot). Da wäre es charmant, wenn man diese großen Blöcke trennen könnte und sagen könnte, ich möchte Aspekt X oder Y davon haben. Das macht aber nur Sinn, wenn sich automatisch die Abhängigkeiten mit installieren.

[Memnarch]

Repositories in componennten aufzuteilen ist noch nicht geplahnt. Schon alleine deswegen, weil ich ein Repo nur im ganzen laden kann.
Was ich eher geplahnt habe ist die implementierung von Projektabhängigkeiten untereinander. Wenn z.B. ein Package Spring4D nutzt, kann das in der info kenntlich gemacht werden und die benötigte Spring4D Version würde beim installieren des Packetes mit installiert. Das kommt aber erst später.

[Benedikt Magnus]

Da ich heute auf dieses umwerfende Projekt gestoßen bin, habe ich Jonas TUbuntuProgress mal unter meinem Githubaccount veröffentlicht (seine Lizenz erlaubt das), da ich es damals schade fand, dass seine Links tot sind und er sich nicht mehr meldet. Zumal ich seit langem den Gedanken spiele, das Projekt zu Firemonkey zu portieren und für 64-Bit zum Laufen zu bringen.

[Memnarch]

Die Suchpfade werdne nicht gehen!

Du hast base angegeben. Damit wird der teil des Pfades der mit Base übereinstimmt im Ziel ohne base hinterlegt.

So wird aus:

Source\Datei.pas
Im Ziel:
Datei.pas

Nim den Base raus ;)
(Und dann eventuell das release nach dem fix nochmal löschen und neuanlegen unter dem aktuellen commit ;))

[Benedikt Magnus]

Interessant. Danke für die Information!

Ist es so nun besser?

[Memnarch]

Jup so siehts besser aus(hast du das Paket etwa nicht getestet :P?)

Die BASE property dient dazu, unnötige ordner ebenen aus dem repo beim kopieren entfernen zu können. Delphinus legt im Ziel bereits einen Ordner Source an(dort landet alles was du dort zum kopieren angegeben hast).

In deinem Fall heißt dass, es liegt im Ziel jetzt der ordner:

PaketName\Source\Source

Mithilfe von base (so wie du es bereits verwendte hattest), hättest du einfach "." als Suchpfad angeben können und im Zielverzeichnis wäre nicht der doppelte Source\Source Ordner ;)

Aber so funktionierts jetzt zumindest.

[Memnarch]

Kleines update mit Websetup und 2 neuen features:
http://memnarch.bplaced.net/blog/201...iled-binaries/

[mquadrat]

Hast du schon eine Idee für das Thema Abhängigkeiten? Wir haben recht viel, was aufeinander aufbaut.

[generic]

Ich wollte gerade mal das Web-Setup testen.
Weit bin ich leider nicht gekommen.
Ein Manifest für Admin-Rechte fehlt oder der vorgeschlagene Pfad ist doof.

Dann mit Adminrechten noch einmal probiert.

Als ich das erste Mal das Setup durchgeklickt habe, hab ich keine Fehlermeldungen angezeigt bekommen.
Allerdings als ich in das Log geschaut habe, ging irgend etwas schief. Wäre schön wenn der Wizard da drauf Hinweisen könnte.

Eine Unschönheit habe ich noch im Bildschirmfoto markiert.

[generic]

Mein Test von der Oberfläche:

Der Optionsdialog reagiert nicht auf die Tasten "ESC" oder "Enter".
Ich kann die Kategorien umbenennen (Bildschirmfoto).

Inzwischen habe ich gerafft, dass der rote Progressbar einen Fehler darstellen soll.
Der ist aber immer so schnell da, dass ich das nicht erkennen konnte.

Aktuell kann ich nicht ein Paket herunterladen.

Zitat:

Downloading Spring4D
Version: 1.1.1
Error: failed to download
deleting tempfiles
Error: Installation failed

Eine richtige Fehlermeldung wäre nicht schlecht.

Ansonsten finde ich die Lösung sehr interessant und hoffe das möglichst viele dein Projekt unterstützen werden.
Ein CLI-Werkzeug wäre noch praktisch ähnlich wie NUGet um Pakete aus Buildskripten nachzuladen.

[Memnarch]

Zitat:

Zitat von generic (Beitrag 1336793)

Aktuell kann ich nicht ein Paket herunterladen.

Kannst du einmal nachsehen, ob der registry-key für den OAuthToken ein Leerzeichen enthält? Leer oder Befüllt(wenn valide) sollte es gehen. Schätze du hast den Dialog geöffnet, vllt ausversehen ein Leerzeichen eingetippt und mit OK bestätigt?

Zitat:

Zitat von generic (Beitrag 1336790)

Als ich das erste Mal das Setup durchgeklickt habe, hab ich keine Fehlermeldungen angezeigt bekommen.
Allerdings als ich in das Log geschaut habe, ging irgend etwas schief. Wäre schön wenn der Wizard da drauf Hinweisen könnte.

Okayy schaut aus als müsste ich doch nochmal extra projektdateien anlegen. Könntest du einmal das XE-Projekt von Delphinus öffnen(in den optionen vllt etwas vor UND zurück stellen) und jweils speichern? Müsste mal gucken ob ich die XE6-Projektdatei dann für XE2-XE5 auch freischalte. Hier fehlen nämlich die Namespaces -.-'

EDIT:

Zitat:

Zitat von mquadrat (Beitrag 1336763)

Hast du schon eine Idee für das Thema Abhängigkeiten? Wir haben recht viel, was aufeinander aufbaut.

Jab habe ich, ist auch schon seit ewigkeiten in der WIki eingetragen(als not yet implemented):
https://github.com/Memnarch/Delphinu...inus.Info.json
Siehe "Dependencies"

[Memnarch]

@generic die Setup sollte nun durchlaufen. Habe dem XE projekt die Namespaces die in den späteren Versionen gebraucht werden hinzugefügt.

[mquadrat]

Ah sorry, hatte ich übersehen, dass das schon in der .json ist.

[generic]

Zitat:

Zitat von Memnarch (Beitrag 1336850)

Zitat:

Zitat von generic (Beitrag 1336793)

Aktuell kann ich nicht ein Paket herunterladen.

Kannst du einmal nachsehen, ob der registry-key für den OAuthToken ein Leerzeichen enthält? Leer oder Befüllt(wenn valide) sollte es gehen. Schätze du hast den Dialog geöffnet, vllt ausversehen ein Leerzeichen eingetippt und mit OK bestätigt?

Ich nutze kein Token, weil ich kein GitHub-Account habe.
Das Wiki verstehe ich auch so, dass es optional ist.

[Memnarch]

Oha @generic, sorry. Habe die Antwort hier übersehen :(
(Nächstes mal lieber nen Bugticket auf Github machen. Dann sollte ichs nicht vergessen).

Ja es sollte optional sein, da gabs aber vor nen Paar Monaten nen Bug. Vielleicht kannst du mal nachgucken obs inzwischen geht?

Außerdem habe ich zur Feier der kostenlosen Starteredition selbige auch als unterstützt hinzugefügt :)
http://memnarch.bplaced.net/blog/201...rter-editions/

[Memnarch]

Malwieder nen Update.
Inzwischen ist das Kommandozeilentool released und Unterstützung für Abhängigkeiten ist in Arbeit!
http://memnarch.bplaced.net/blog/201...es-are-coming/

Grüße
Memnarch

[Memnarch]

nach langem wieder nen update.
- Mobile/Linux als targets für die Pakete freigeschaltet
- Bitbucket wird nun unterstützt(über das aufsplitten und verlinken von Repos)
- neue property für externe Bugtracker

Details:
http://memnarch.bplaced.net/blog/201...-mobile-linux/