Neuer OpenSource Package Manager

[sh17]

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

[Memnarch]

Zitat von sh17:

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

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