Neuer OpenSource Package Manager

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