Neuer OpenSource Package Manager

[mkinzler]

Mal was anderes, was bei 3 verfügbaren Produkten noch nicht ins Gewicht fällt (was sich hoffentlich bald ändert!).
Ich würde vorschlagen eine Klassifizierung für die verfügbaren Packages einzuführen.
Neben den verfügbaren Plattformen (welche ja schon angebbar sind) und den Forks (wie SirRufo schon vorgeschlagen hat) würde ich noch:
-die Programmiersprache/Personality ( Delphi/C++/...)
-Lizenz
-UI Bibliothek ((VCL, FMX, ...)
-Stabilität ( Alpha/Beta/Stabil/...)
-Sprache ( englisch/deutsch/spanisch/...)
-Klassifizierung nach Zweck/Bereich ( RTL/UI/DB/...)

Auch wenn die Unterstützung im Tool erst nach und nach erfolgt würde ich die Möglichkeit der Angabe schon jetzt vorsehen.
Da sowieso schon eine info.json angelegt werden muss, wäre die Erweiterung dieser ja problemlos möglich.

[Der schöne Günther]

Auch wenn ich das hier bislang nicht wirklich verfolgt habe: Lizenz ist absolutes Muss, aber "Zweck/Bereich" finde ich nie eindeutig und nur schwer festzulegen. Auch: Wenn man einmal damit anfängt, vordefinierte Bereiche zu schaffen sind die nie genug.

[mkinzler]

Die Bereiche kann man ja später anpassen/erweitern. Auf GitHub gibt es momentan knapp 1600 Projekte in Pascal, von denen hoffentlich Einige ihre Produkte "Delphinus"-fähig machen werden. Ab einer bestimmten Anzahl wird es unübersichtlich.

[Sir Rufo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1313389)

Auch wenn ich das hier bislang nicht wirklich verfolgt habe: Lizenz ist absolutes Muss, aber "Zweck/Bereich" finde ich nie eindeutig und nur schwer festzulegen. Auch: Wenn man einmal damit anfängt, vordefinierte Bereiche zu schaffen sind die nie genug.

Wieso sollten die auch vordefiniert sein. Da gibt es einfach eine Tag-Liste und dort kann der Package-Ersteller reinschreiben, was er möchte. Nach diesen Tags kann dann gesucht werden.

Schon wird ein Schuh draus

[sh17]

Zitat:

Zitat von mkinzler (Beitrag 1313390)

Die Bereiche kann man ja später anpassen/erweitern. Auf GitHub gibt es momentan knapp 1600 Projekte in Pascal, von denen hoffentlich Einige ihre Produkte "Delphinus"-fähig machen werden. Ab einer bestimmten Anzahl wird es unübersichtlich.

hab mal

https://github.com/norgepaul/TChromeTabs

angestubst

[mkinzler]

Danke.

[Memnarch]

Zitat:

-die Programmiersprache/Personality ( Delphi/C++/...)

Macht sinn, hab nur gerade kein C++ Builder. Muss ich irgendwas beachten? ich kanns schlecht testen.

Zitat:

-Lizenz

Das ist auch geplahnt. Wobei ich überlege das über die GithubApi zu lösen(da kann ich ja auch nach der Lizenz eines projektes fragen). Aber im Package(also der Typ) ist wwohl besser. Schont auch das RateLimit^^

Zitat:

-UI Bibliothek ((VCL, FMX, ...)
-Klassifizierung nach Zweck/Bereich ( RTL/UI/DB/...)

Es wurde auf G+ bereits nach Kategorien gefragt. Das lässt sich sicher Kombinieren. Bei einer Property könnte man ja auch Tag-Mässig mehrere Kategorien angeben.

Zitat:

-Stabilität ( Alpha/Beta/Stabil/...)

Das könnte ich eigentlich auch per Github-Api abfragen, aber auch hier ist der Ansatz mit direkt in die Info.json vielleicht besser.

[mkinzler]

Was direkt über die GitHubApi geht würde ich über diese lösen. Nur was darüber hinausgeht würde ich zusätzlich lösen.
Eine doppelte Angabe von Informationen ist ja überflüssig und fehleranfällig ( z.B. Lizenz ändert sich und wird nur an einer Stelle angepasst).

Die Lösung über Tags ist gut, ich würde aber eine Liste Kategorie-Tags vorgeben, welche bevorzugt verwendet werden sollen, sonst entseht ein Synoymwildwuchs. Weitere Tags darf jeder natürlich selbst festlegen.

[sh17]

ok, TChromeTab werd ich selbst anpassen müssen, da brauch ich aber erst die Checkbox um Forks einbinden zu können. Paul hat keine Zeit momentan, er merged dann nur, wenn es fertig ist

[Memnarch]

Zitat:

Zitat von mkinzler (Beitrag 1313400)

Was direkt über die GitHubApi geht würde ich über diese lösen. Nur was darüber hinausgeht würde ich zusätzlich lösen.
Eine doppelte Angabe von Informationen ist ja überflüssig und fehleranfällig ( z.B. Lizenz ändert sich und wird nur an einer Stelle angepasst).

ja und nein. GithubApi ist bequem. Jede request die tatsächlich neue Daten liefert, kostet mich einen RateLimit-Punkt. Und wenn das Package später mal über eine Nicht-Gitub-SOurce installiert werden soll, muss die info eh rein. Außerdem "Evaluiert" Github anhand des Lizenztextes, wass das sein könnte. Würde das jetzt nicht Fehlerfrei nennen ;)
Mal abgesehen davon ist die API noch in der Preview.

https://developer.github.com/v3/licenses/

Package ist zwar dann irgendwo doppel, aber auch einfacher.

Okay sehe gerade, ich bekomm die Lizenz schon in der Repoinformation. Da wäre Github dann viel einfacher, und custom lizenzen werden auch als solche gekenzeichnet. Passt :D