Neuer OpenSource Package Manager

[sh17]

Ich merk schon, ich muss da nix mehr machen Danke

Zitat von mkinzler:

Zitat:

Dein Wort in Gottes Ohr

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

[mkinzler]

Zitat von sh17:

Ich merk schon, ich muss da nix mehr machen Danke

Zitat von mkinzler:

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

[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 von 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?

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 von 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.

Siehe Mormot

Zitat von mkinzler:

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 von Memnarch:

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 von Uwe Raabe:

Zitat von Memnarch:

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.