Als IDE Plugin lässt sich sowas schlecht implementieren, es müsste ja für das Bauen der Pakete die jeweilige Distribution in jeder Version heruntergeladen werden dann installiert man die Abhänigkeiten und schließlich baut man das Paket. Den ganzen Prozess führt man dann für x86_64, x86, ARMv6 und ARMv7 durch. OpenSUSE bietet aber in der Tat sowas ähnliches mit dem OpenSUSE Build Service an. Das bietet dem Entwickler aber noch nicht die Möglichkeit z.B. python 3.5 als Dependency für sein Projekt einzuführen, weil in den meisten Distributionen kein Python 3.5 verfügbar ist. Python ist hier natürlich nur ein Beispiel, stellvertretend für alle Abhängigkeiten.
Ja das geht schon in die Richtung aber das dann offline und entsprechend optimiert. Sicherlich könnte man dann auf Basis von Containern oder VMs die Systeme vorhalten. Sicherlich ein nicht unerheblicher Aufwand was die Entwicklung so einer Anwendung angeht, aber ganz sicher würden viele Entwickler das nutzen. Wäre der Bedarf nicht da, wäre ja der OpenSUSE Build Service ein Trauerspiel, die Praxis zeigt aber das Gegenteil.
Das OpenSUSE Build System ist OSS wie Suse selbst, also einem Betrieb auf dem eigenen Rechner steht nichts entgegen. Aber ich persönlich hätte aber keine Lust ne ganze Build-Farm auf meinem Rechner zu betreiben, zum einen wegen des Platzes den es unnötig nimmt und zum anderen weils langsam ist. Letztendlich baut man damit dann auch nur die Pakete, das Repository muss man dann noch gesondert betreiben… das kann ich entspannter bei OpenSUSE Build direkt haben.
Snappy löst übrigens aber auch noch ein paar andere Probleme für 3th Party Entwickler wie z.b. die Integration von Apparmor, Cgroups, Kernel Namespaces und damit einen Shift des Vertrauens bis zu einem gewissen Grad vom Entwickler zum Betriebssystemhersteller.
Als IDE Plugin lässt sich sowas schlecht implementieren, es müsste ja für das Bauen der Pakete die jeweilige Distribution in jeder Version heruntergeladen werden dann installiert man die Abhänigkeiten und schließlich baut man das Paket. Den ganzen Prozess führt man dann für x86_64, x86, ARMv6 und ARMv7 durch. OpenSUSE bietet aber in der Tat sowas ähnliches mit dem OpenSUSE Build Service an. Das bietet dem Entwickler aber noch nicht die Möglichkeit z.B. python 3.5 als Dependency für sein Projekt einzuführen, weil in den meisten Distributionen kein Python 3.5 verfügbar ist. Python ist hier natürlich nur ein Beispiel, stellvertretend für alle Abhängigkeiten.
Ja das geht schon in die Richtung aber das dann offline und entsprechend optimiert. Sicherlich könnte man dann auf Basis von Containern oder VMs die Systeme vorhalten. Sicherlich ein nicht unerheblicher Aufwand was die Entwicklung so einer Anwendung angeht, aber ganz sicher würden viele Entwickler das nutzen. Wäre der Bedarf nicht da, wäre ja der OpenSUSE Build Service ein Trauerspiel, die Praxis zeigt aber das Gegenteil.
Das OpenSUSE Build System ist OSS wie Suse selbst, also einem Betrieb auf dem eigenen Rechner steht nichts entgegen. Aber ich persönlich hätte aber keine Lust ne ganze Build-Farm auf meinem Rechner zu betreiben, zum einen wegen des Platzes den es unnötig nimmt und zum anderen weils langsam ist. Letztendlich baut man damit dann auch nur die Pakete, das Repository muss man dann noch gesondert betreiben… das kann ich entspannter bei OpenSUSE Build direkt haben.
Snappy löst übrigens aber auch noch ein paar andere Probleme für 3th Party Entwickler wie z.b. die Integration von Apparmor, Cgroups, Kernel Namespaces und damit einen Shift des Vertrauens bis zu einem gewissen Grad vom Entwickler zum Betriebssystemhersteller.