Composer möchte 1 GB RAM haben...

[Georgi]

Suche ich mir ein Hosting, auf dem der Composer gut läuft oder suche ich ein Hosting für Contao?

Dem kann ich absolut nur zustimmen! Ich habe mich bewusst für Contao entschieden, weil man damit tolle Webseiten machen kann, ohne großer Programierer sein zu müssen. Gerade die beiden von mir betreuten Vereinsseiten (eine sogar mit einem Ticketshop) lassen sich gut händeln, auch im Hinblick darauf, dass sie biologisch mal von einem anderen Verantwortlichen weiter gepflegt werden müssen. Meine beiden Hostingpakete (1und1 mtl. 9,99 Euro, 128 MB RAM und alfahosting mtl 5,99 Euro, 120 MB RAM) mögen zwar preiswert sein, passen aber in das Budget der beiden Vereine.

Gestern bin ich also bei der einen HP wieder auf die alte Erweiterungsverwaltung zurückgegangen, die im Hinblick auf den Composer wesentlich unübersichtlicher ist und ich nun auch manuelle Installationen habe, die dort nicht sichtbar sind. Am Wochenende kommt dann wohl die andere dran. Dann sind die Seiten wieder im Hinblick auf die aktuelle Pflege der Erweiterungen wieder händelbar.

Sollte beim Composer in Kürze keine Lösung kommen (er ist bei mir seit einem halben Jahr ein ständiges Problem und jetzt kann ich nichts mehr verstellen, sondern nur noch weiteren RAM einkaufen), dann muss ich wohl auch von Contao Abschied nehmen. Schade.

Gruß Georgi

[Thraile]

Und dann? Bei allen größeren Projekten hängt irgendwo der Composer mit drin. Das Ganze ist ja jetzt kein Contao only Problem.

So sehr die Situation im Moment gerade auch nervt, ich glaube nicht, dass man langfristig an Composer vorbei kommt.

Momentan behelfen wir uns mit einem lokalen Entwicklungsserver, wo Php eben viel RAM hat. Für den Abgleich kann man ja SyncCto oder andere Tools benutzen.

Gesendet von meinem D5803 mit Tapatalk

[MacKP]

Meine beiden Hostingpakete (1und1 mtl. 9,99 Euro, 128 MB RAM und alfahosting mtl 5,99 Euro, 120 MB RAM) mögen zwar preiswert sein, passen aber in das Budget der beiden Vereine.

Äh.. mal ernsthaft: Das Paket von 1und1 ist ein Witz. Die 128MB sind als 'bis zu' ausgeschrieben. Oft genug bekommt man da nur 32MB, weil alle anderen auf dem Server eben auch RAM brauchen. Auf Konsole sieht es nicht wirklich besser aus. Selbst bei den Paketen, wo man garantiert 2GB RAM hat gillt das nicht für den einzelnen PHP-Prozess. Da hab ich dann tatsächlich 128MB (so ca.) und auf Konsole sogar nur 80MB.
Vergleichbare Hosting Anbieter bringen einem da schon mehr für 10 Euro im Monat. Beispiel Domainfactory: Da hat man zwar 'nur' 128MB und ne laufzeit von 60 Sekunden, allerdings ist das auf der Konsole nicht so beschränkt. Wenn man Komposer dann umstellt hat man weniger Probleme als wo anders. Für alfahosting kann ich das nicht sagen, da hab ich keine Erfahrung mit.
Es ist eben doch wichtig, wo man Hostet! Das war es schon immer und wird immer so bleiben.

Allgemein zu Composer: Lest euch doch mal die älteren Beiträge durch, warum Composer genommen wurde/wird. Eventuell auch den Antrag an die Association. Dann wird euch klar, das es nicht zum Spaß gemacht wurde und warum das der richtige Schritt ist (ja, wir sind da auch nicht die einzigen, die diesen Schritt gehen.. bei anderen CMS könnt ihr auch nachlesen, warum Composer genommen wird). Es bringt auch nichts immer nur rumzumosern. Schauen wir doch lieber, wie wir die Energie nutzen können um dann etwas an den Problemen zu tun!

Viele Grüße

[Toflar]

Ich hab gestern mal wieder bis morgens um 2 nachgeforscht und ein POC für einen solchen Cloud-Service geschrieben. Es ist also nicht so, als wäre uns das Problem nicht bekannt oder würde uns nicht beschäftigen
Ich denke es würde funktionieren, aber die Last ist schon heavy. Angenommen wir haben 1000 Benutzer die 5x am Tag ein Update klicken (und ich weiss nicht was ihr denkt, aber 1000 User sind irgendwie noch nicht so viel) und ein Update dauert 30 Sekunden. Dann sind das 5000 x 30 Sekunden also 150’000 Sekunden Arbeit. Also rund 42h. Verteilt auf einen Tag (sind wir realistisch, 10h davon pennen die Leute bzw. ist eher idle-time, also auf 14h aufgeteilt) bräuchten wir also schon mind. 3 dedizierte Worker mit genug RAM (mind. 1 GB bzw. sobald jemand "min-stability: dev" nutzen will, wohl eher 2 GB) die rund um die Uhr nur Abhängigkeiten auflösen. Die Infrastrukturkosten wären schon so relativ hoch und mit der steigenden Anzahl Nutzer natürlich auch Tendenz steigend.
Hinzu kommt, dass wir einen neuen Single Point of Failure haben bzw. sich auch jemand um die Infrastruktur, das Load-Balancing etc. kümmern müsste. Alles machbar, aber ich fürchte dann muss jeder, der diese Cloud nutzen will, sich irgendwie an den Kosten beteiligen (mind. Mitglied bei der Association sein etc.).

Das Prinzip ist relativ einfach. Die "composer.json" wird zusammen mit den Plattform-Informationen (PHP-Version, PHP-Extensions etc.) an die Cloud geschickt. Die löst damit die Abhängigkeiten auf und antwortet (natürlich nicht direkt, man würde eine Job-ID erhalten und könnte erst nach x Minuten das Update effektiv dann durchführen) mit einer "composer.lock"-Datei. Damit kann man dann auf dem Server Composer darum bitten, nicht die Abhängigkeiten aufzulösen sondern das zu installieren, was in der "composer.lock" steht (für die Techies: "composer install" statt "composer update"). Da er da nichts mehr berechnet, sondern nur noch installiert braucht das natürlich viel, viel weniger RAM und die ganze Symlink-Sache und Module nach system/modules kopieren etc. würde immer noch funktionieren.

Nachteile sind wie gesagt: Man muss warten bis der Job durchgelaufen ist und die Infrastrukturkosten.

Die Alternative die mir einfällt ist ein Desktop-Tool, bei dem man die composer.json und die Plattforminfos reinkopiert, "Abhängigkeiten auflösen" klickt und somit die Ressourcen des eigenen Computers braucht. Dann kriegt man eine "composer.lock" die man dann wiederum in die GUI auf dem Webserver kopiert und da "Pakete installieren" klickt. Das wäre das gleiche Prinzip, einfach die Last auf den eigenen Computer verlagert. 2 GB RAM sind ja da auch kein Thema.

Nachteil: Man muss halt Copy-Pasten und braucht ein Desktop-Tool, wenn man sich auf der Kommandozeile nicht wohlfühlt. Das Desktop-Tool wiederum sollte auf Linux, Mac, Windows laufen und man kann es halt nicht von unterwegs machen (wobei ich noch nie von unterwegs eine Contao-Installation geupdated hab ).

Was für mich persönlich aber nicht zur Debatte steht ist ob Composer die richtige Lösung ist. Wir Entwickler brauchen Composer. Er ist ein Muss für die moderne, professionelle PHP-Entwicklung und ich bin überzeugt, dass alle PHP-basierten Systeme mit Erweiterungsmöglichkeiten vor diesem Problem stehen. Wir müssen eine Lösung finden, wie PHP-Entwickler die volle Power von Composer nutzen können, gleichzeitig normale Anwender nicht überfordert sind und die Serveranforderungen nicht ins Unermessliche steigen. Das Problem ist nur leider so komplex, dass es dauern wird, bis wir diese Lösung gefunden haben.

Insofern müssen wir sehr genau darauf Acht geben, dass wir nicht unnötig Schuldzuweisungen machen und einander gegenseitig verärgern. Composer ist nicht schlecht, im Gegenteil. Die Anforderungen ergeben sich einfach durch die Komplexität des Problems, da kann Composer nix für. Den Entwicklern geht das Problem auch nicht am Arsch vorbei, sondern es ist einfach kompliziert. Die Frontend'ler sind genervt, weil sie sich mit etwas beschäftigen müssen, was sie lieber nicht möchten. Sie fürchten sich (noch) vor der Kommandozeile und es kommen immer mehr Tools dazu, von "grunt" zu "bower" und jetzt auch noch "composer".
Alles verständlich. Versuchen wir einfach das Problem anzunehmen wie es ist und gemeinsam nach einer Lösung zu suchen, ohne dass wir auf dem Weg User und/oder Entwickler verlieren Immerhin ist hier immer noch alles Open-Source und keiner hat einen Anspruch auf die Arbeitszeit des anderen.

[Georgi]

Es bringt auch nichts immer nur rumzumosern.

Ich will nicht rummosern, ich will nur, dass meine Installation auch mit Composer läuft, was bisher ja möglich war.

Ich möchte aber nicht, dass der Klick auf "Testlauf" zur Zitterpartie wird (und mit out of memory endet). Und ich möchte bei Contao bleiben !!

Ich sehe aber nicht, dass eine Lösung naht.

Vergleichbare Hosting Anbieter bringen einem da schon mehr für 10 Euro im Monat. Beispiel Domainfactory: Da hat man zwar 'nur' 128MB und ne laufzeit von 60 Sekunden, allerdings ist das auf der Konsole nicht so beschränkt. Wenn man Komposer dann umstellt hat man weniger Probleme als wo anders.

... und wer garantiert einem dann, dass nicht dort nicht auch nach einem halben Jahr wieder Schluss ist (out of memory)?

Gruß Georgi

[Spooky]

Ich sehe aber nicht, dass eine Lösung naht.

Eine kurzfristige Lösung wird sein, dass du das composer update (zwei mal, oder wie auch immer es dann sein muss) lokal auf deinem Rechner machst und dann die composer.lock Datei auf den Server spielst und dort dann (durch ein weiteres update des composer-clients) einen "Pakete installieren" button betätigen kannst.

Ich denke sowas sollte als Hotfix gleich eingebunden werden, damit man diesen Workaround auch auf Servern ohne Konsolenzugriff durchführen kann (ohne immer gleich ein komplettes re-deployment machen zu müssen).

[MacKP]

... und wer garantiert einem dann, dass nicht dort nicht auch nach einem halben Jahr wieder Schluss ist (out of memory)?

Hallo Georgi,
dir kann niemand irgendwas garantieren. Wie Toflar schon geschrieben hat, wird aber geschaut, das dieses Problem in den Griff bekommen wird.
Ich kann dir nur sagen, das dein Hoster für den Preis einfach nicht gut ist und die Werte nicht das sind, was die versprechen. Da kommst du auch ohne Composer schnell an Grenzen. Selbst wenn es das aktuelle Problem nicht geben würde, hättest du da keine Freude und nur Probleme.

Viele Grüße

[tab]

Eine kurzfristige Lösung wird sein, dass du das composer update (zwei mal, oder wie auch immer es dann sein muss) lokal auf deinem Rechner machst und dann die composer.lock Datei auf den Server spielst und dort dann (durch ein weiteres update des composer-clients) einen "Pakete installieren" button betätigen kannst.

Ich denke sowas sollte als Hotfix gleich eingebunden werden, damit man diesen Workaround auch auf Servern ohne Konsolenzugriff durchführen kann (ohne immer gleich ein komplettes re-deployment machen zu müssen).

Wenn das so möglich ist, wäre das doch eine brauchbare Lösung, zumindest bis es vielleicht doch mal was einfacheres gibt. Irgendwas brauchen wir da. Sicher, man kann das Hosting wechseln, manchmal wird das aber an anderer Stelle entschieden. Und da kann man leider nicht immer Einsicht erwarten.

Gleichzeitig denke ich aber auch, wir sollten uns Gedanken machen, ob das zu lösende Problem wirklich so komplex sein muss oder ob man es vereinfachen kann. Ich denke da z.B. an "Metapakete", die dann in sich schon durchgerechnet sind, eventuelll auch in mehreren Varianten, damit man etwas Auswahl hat, wenn sich das mit anderen Paketen beißt (die irgendeine enthaltene Erweiterung zwingend in einer anderen Version brauchen). Letztlich "weiss" man doch aus Erfahrung, welche Erweiterungen besonders kritisch sind in dieser Hinsicht. Warum sollte man solches Wissen nicht in irgendeiner Form einfliessen lassen? Und auf der Composer-Seite überlegen, ob man da nicht was machen kann, was den Memorybedarf verringert und ggf (nichts ist umsonst, auch in der Programmierung) nicht ganz so schnell ist und intelligentere, komplexere Algorithmen erfordert. Ich denk mal, das ist ja auch im Sinne der Composer-Entwickler, insofern wird da wahrscheinlich auch dran gearbeitet.

[Ulrich]

... Für alfahosting kann ich das nicht sagen, da hab ich keine Erfahrung mit. ...

Bei Alfahosting musste ich für ein Projekt, bei dem ich konsequent mit dem Composer arbeiten möchte (settings: composer.png), von dem Paket Multi XXL (für derzeit monatl. 5,99 Euro mit max. 128 MB PHP memory_limit) auf das Paket Business XXL (für derzeit monatl. 16,99 Euro mit max. 512 MB PHP memory_limit) upgraden.

Mit den aktuellen composer settings (minimale Stabilität = Alphaversion) läuft das Update gerade noch so, aber mit der Auflösung der Abhängigkeiten für Entwicklerversionen, ist auch hier die Kapazität derzeit zu gering. Abgesehen davon war ich bisher mit Alfahosting zufrieden, auch die FTP-Verbindungen laufen mit einer akzeptablen Bandbreite. Doch inzwischen bin ich einigermaßen verärgert über diesen Anbieter:

Aufgrund der derzeitigen Situation mit dem Composer und einer noch dauernden vertraglichen Bindung innerhalb einer Mindestlaufzeit, wollte ich einen vServer bei Alfahosting ausprobieren. Den Einstiegstarif, vServer M für derzeit monatl. 12,99 Euro, bietet Alfahosting kostenlos zum Test an. Leider stellte sich heraus, dass der Testserver mit völlig veralteter Software lief (PHP!!!), so dass die Plattform nicht mit der aktuellen Contao 3.5.6 kompatibel war. Alfahosting war NICHT bereit, einen Testserver mit aktueller Software zur Verfügung zu stellen. Ergo: Nach Ablauf der Mindestlaufzeit, die leider wegen des letzten Upgrades wieder neu angelaufen ist, werde ich auf jeden Fall den Provider wechseln!

Bleibt noch anzumerken, dass ein vergleichbarer Testserver bei 1 und 1 zwar mit aktueller Software installiert war und der Test erfolgreich laufen konnte, aber die FTP-Verbindungen deutlich langsamer liefen, als bei Alfahosting, deutlich zu langsam, um damit vernünftig arbeiten zu können ...

[mlweb]

Momentan behelfen wir uns mit einem lokalen Entwicklungsserver, wo Php eben viel RAM hat. Für den Abgleich kann man ja SyncCto oder andere Tools benutzen.

Wobei ich denke das so etwas für den Entwickler oder den professionellen Webdesigner eine gute Lösung für das momentane Problem ist. Für @Georgi mit seinen zwei Vereinsseiten und die Leute die sich durchgekämpft haben um Ihre eigene Seite aufzubauen wohl eher nicht. Auch wenn wir nicht versprechen, dass man ohne jede Kenntnis mit ein bisschen Klicken schöne Firmenwebseiten bauen kann, dürfen wir diese Nutzer nicht aus dem Auge verlieren. Das wäre fatal.

[lucina]

Dem kann ich absolut nur zustimmen! Ich habe mich bewusst für Contao entschieden, weil man damit tolle Webseiten machen kann, ohne großer Programierer sein zu müssen. Gerade die beiden von mir betreuten Vereinsseiten (eine sogar mit einem Ticketshop) lassen sich gut händeln, auch im Hinblick darauf, dass sie biologisch mal von einem anderen Verantwortlichen weiter gepflegt werden müssen. Meine beiden Hostingpakete (1und1 mtl. 9,99 Euro, 128 MB RAM und alfahosting mtl 5,99 Euro, 120 MB RAM) mögen zwar preiswert sein, passen aber in das Budget der beiden Vereine.

Gestern bin ich also bei der einen HP wieder auf die alte Erweiterungsverwaltung zurückgegangen, die im Hinblick auf den Composer wesentlich unübersichtlicher ist und ich nun auch manuelle Installationen habe, die dort nicht sichtbar sind. Am Wochenende kommt dann wohl die andere dran. Dann sind die Seiten wieder im Hinblick auf die aktuelle Pflege der Erweiterungen wieder händelbar.

Sollte beim Composer in Kürze keine Lösung kommen (er ist bei mir seit einem halben Jahr ein ständiges Problem und jetzt kann ich nichts mehr verstellen, sondern nur noch weiteren RAM einkaufen), dann muss ich wohl auch von Contao Abschied nehmen. Schade.

Gruß Georgi

Irgendwie verstehe ich Dich nicht so ganz - tolle Webseiten machen und tolle Webseiten produktiv ausliefern sind doch nun wirklich zwei paar Schuhe.

Produktiv ausliefern kannst Du ja auch über die (sorry) Grütze-Hoster wie 1und1. Produktivsysteme sind für mich auch keine, die großartig Abhängigkeiten zu Entwicklerversionen auflösen müssten. Die sind Stable, nutzen Stable und sonst gar nichts. Alles andere wäre auch fahrlässig, gerade in bezug auf ein Ticket-Shopsystem.

Für's Webseiten entwickeln ist das etwas anderes. Dazu bin ich entweder lokal auf meinem Server, oder ich bin bei einem Anbieter, der mir die Ressourcen zur Verfügung stellt die ich benötige. Ich bin definitiv nciht bei 1und1 oder Alfahosting, sondern eher auf einem eigenen Server, ob nun managed oder nicht.

Und dabei befinde ich mich ganz sicher nicht in der <einstelligen Betrag einsetzen>,99 €-Klasse.

Just my two cents.

[mlweb]

Ich kann dir nur sagen, das dein Hoster für den Preis einfach nicht gut ist und die Werte nicht das sind, was die versprechen.

Das kann man nur immer wieder betonen. Ich weiss wovon ich rede. Ich habe auch einige Kunden bei 1&1. Nicht alle lassen sich zu einem Domainumzug überreden.

[lucina]

Ich kommuniziere den Mehraufwand und stelle ggf. auch eine Rechnung dafür. Dann regelt sich das eigentlich immer ein.

Für Leute, die selbst mit dem Bäcker um den Brötchenpreis feilschen möchte ich nicht arbeiten.

[Georgi]

@mlweb und @lucina:
Nur zum Verständnis: Ich bin kein professioneller Webdesigner, sondern habe mich von html auf Contao "hochgearbeitet".

Für Leute, die selbst mit dem Bäcker um den Brötchenpreis feilschen möchte ich nicht arbeiten.

Darum geht es bei mir Gott sei Dank nicht! Ich mache das aus Spaß an der Freude ...

Eine kurzfristige Lösung wird sein, dass du das composer update (zwei mal, oder wie auch immer es dann sein muss) lokal auf deinem Rechner machst und dann die composer.lock Datei auf den Server spielst und dort dann (durch ein weiteres update des composer-clients) einen "Pakete installieren" button betätigen kannst.

Ich werde das jetzt mal versuchen.

[mlweb]

Ich kommuniziere den Mehraufwand und stelle ggf. auch eine Rechnung dafür. Dann regelt sich das eigentlich immer ein.

Nicht immer. Mein ganz renitenter Kunde hat ein uraltes Paket bei 1&1 für knapp zwei Euro aber mit einer Datenbank. Contao funktioniert natürlich nur mit dem ER2 und sicher auch nur deshalb, weil nur sehr wenige und kleine Erweiterungen installiert sind. Die Seite ist eher statisch. Der sagt mir ganz klar, solange es machbar ist, bezahle ich Ihnen lieber den Mehraufwand, als das ich mehr an irgendeinen Provider zahle.

[Ulrich]

... Der sagt mir ganz klar, solange es machbar ist, bezahle ich Ihnen lieber den Mehraufwand, als das ich mehr an irgendeinen Provider zahle.

Na dann ... immer fleißig Rechnungen schreiben!

[mlweb]

Na dann ... immer fleißig Rechungen schreiben!

Na klar.

[tab]

Für wirklich produktive Seiten wird man ein Update sowieso selten auf dem Live-System durchführen. Allerdings hat sich da bei mir aus Bequemlichkeit eine andere Vorgehensweise eingeschlichen, ich mache Updates oft in einem anderen Unterverzeichnis des selben Webspace mit einer Subdomain. Das wird dann halt mit Composer so erst einmal nicht mehr gehen, weil da auch nicht mehr RAM zur Verfügung steht. Muss ich wohl bei Composerinstallationen, die tendenziell natürlich zunehmen werden, fürs Erste wieder zurück auf den lokalen Rechner. Ist aber auch kein großes Ding, sooo oft update ich die Erweiterungen bei produktiven Installationen nicht. Contao (Bugfix-)Updates sollten ja eigentlich nicht betroffen sein, oder?

[mlweb]

Ich schau eigentlich bei jedem Update von Contao auch ob es Updates für die Erweiterungen gibt. Meist führe ich dort dann auch gleich das Update durch.
Core Updates werden zumindesten in Contao 3 (noch) nicht mit Composer gemacht, es sei denn es schleicht sich ein Fehler ein wie vor kurzem passiert.

[Georgi]

Eine kurzfristige Lösung wird sein, dass du das composer update (zwei mal, oder wie auch immer es dann sein muss) lokal auf deinem Rechner machst und dann die composer.lock Datei auf den Server spielst und dort dann (durch ein weiteres update des composer-clients) einen "Pakete installieren" button betätigen kannst.

Danke mit Contao2Go habe ich jetzt eine (Zwischen)Lösung gefunden:
https://community.contao.org/de/show...l=1#post399949

[FloB]

Hast du einen PoC Code, der das automatisieren könnte? Sprich, auf der einen Seite schiebst du compose.json + Plattforminfos (Welche sind das? Hast du dafür ein Script, was diese Plattforminfos ausliest und in maschinenlesbarer Form ausgibt?) rein, auf der anderen Seite kommt eine compose.lock raus.

Die Alternative die mir einfällt ist ein Desktop-Tool, bei dem man die composer.json und die Plattforminfos reinkopiert, "Abhängigkeiten auflösen" klickt und somit die Ressourcen des eigenen Computers braucht. Dann kriegt man eine "composer.lock" die man dann wiederum in die GUI auf dem Webserver kopiert und da "Pakete installieren" klickt. Das wäre das gleiche Prinzip, einfach die Last auf den eigenen Computer verlagert. 2 GB RAM sind ja da auch kein Thema.

Ich würde das mal (auf Basis des PoC) als Docker-Container + kleine API verpacken, dann könnte man mal austesten, wie gut das funktioniert und ggf. einen Service draus machen (wer den Container für "seine" Projekte selber aufsetzen möchte, kann das natürlich gerne tun ). Von da aus kann man dann sicherlich relativ easy auch ein Desktop-Tool draus machen.

[Georgi]

@FloB
wenn du mich meinst:

PoC Code

verstehe ich nur "Bahnhof"; das ist eine Nummer zu groß für mich.

Aber ich beschreibe dir gern, was ich gemacht habe: Composer auf dem Webserver hatte Vers. 0.16.2, Testlauf + Pakete aktualisieren endeten am memory_limit und dann stand bei composer irgendetwas wie: es gibt eine neue Vers. 0.16.3.
In C2G konnte ich problemlos auf die 0.16.3 aktualisieren. Anschließend habe ich von C2G per WinSCP (synchroisieren) die Datei nach !composer geschoben (war's noch nicht) und dann nach /root/composer; das war's.

[Znrl]

Sprich anderer Server zum updaten und dann zurück syncen/spiegeln.

Das andere ginge quasie in die Richtung, dass man dem Composer beibringen müsste (im Idealfall) aus dem Contao Backend ein Update zu fahren (nur noch Download und Installation) anhand einer vorher woanders ausgeführten Abhängikeitsauflösung (und sich diese eben spart).
Das geht ja so meines wissens noch nicht. Vtl. halt direkt über den Composer.

Sowas ginge ja in die Richtung:
https://composer.borreli.com/
https://community.contao.org/de/show...highlight=znrl
Mit gewissen Nachteilen allerdings, wie dort von Tristan angemerkt.

[FloB]

Sorry, war @Toflar gedacht!

PoC = Proof of Concept

[Toflar]

Jau, ich hab meine Cloud hier am rennen. Ist eine kleine Silex-Applikation die momentan noch einen normalen Prozess forkt und Composer ausführt, anstatt direkt die Lib zu nehmen, aber läuft soweit problemlos. Funktioniert über RabbitMQ und Redis und ich muss noch die "installed.json" berücksichtigen. Aber ich kann sagen, es wäre definitiv machbar. Ich hab dich mal meinem private Repo hinzugefügt, kannst gucken wenn du magst :-) Aber die Kosten müssen die Nutzer tragen und ich weiss nicht, wer bereit ist, dafür zu zahlen. Diese Mentalität, dass man für gewisse Dinge was zahlen muss, fehlt in unserer Community einfach (noch).

[Znrl]

Bei einem (öffentlichen) externen Server zum Auflösen gäbe es halt noch den Nachteil mit privaten Repositorys, da will man ja nicht unbedingt die Zugangsdaten mitliefern.
Hier wären "Desktoptools" oder Lösungen für den eigenen Server zumindest zusätzlich ganz praktisch.

Ich hatte mich auch schon gefragt ob man nicht gewisse Abhängikeiten cachen oder irgendwie indexieren (Prinzipiell auch vorausberechnet für häufig abgefragte Kombinationen) könnte.

Bei deinem Beispiel mit den 1000 Leuten, die 5 mal am Tag Update klicken...
Könnte man ja annehmen, dass sich da nicht ständig was ändert.
800 haben nichts installiert/deinstalliert, von denen gab es bei 400 keine Updates/Änderungen der Extensions.
Wenn der Server das erkennt kann die Last gleich halbiert werden oder mehr.

Ich könnte mir vorstelen, dass es gewisse Kombinationen recht oft gibt, insbesondere auch, da einige Extensions auch gar keine Abhängigkeiten zueinander haben und somit im Grunde von gewissen "Grund"-Kombinationen unabhängig sind.

[Spooky]

Bei deinem Beispiel mit den 1000 Leuten, die 5 mal am Tag Update klicken...
Könnte man ja annehmen, dass sich da nicht ständig was ändert.
800 haben nichts installiert/deinstalliert, von denen gab es bei 400 keine Updates/Änderungen der Extensions.
Wenn der Server das erkennt kann die Last gleich halbiert werden oder mehr.

Das bringt ja nichts, sofern die composer.jsons nicht gleich sind, kann man ja nicht wissen was das Ergebnis ist.

[tab]

Ich könnte mir vorstelen, dass es gewisse Kombinationen recht oft gibt, insbesondere auch, da einige Extensions auch gar keine Abhängigkeiten zueinander haben und somit im Grunde von gewissen "Grund"-Kombinationen unabhängig sind.

Das hatte ich mit den "Metapaketen" gemeint. Also sowas wie z.B. die Metamodels Bundles.

[MacKP]

MM bundle_all ist da ein recht blödes Beispiel. Natürlich hat das dnan eben noch mehr Kombinationen. Und vor allem ist MM abhängig vom DCG, wie ein paar andere Erweiterungen. Das muß individuell geprüft werden.
Genau gleiche Kombinationen dürften recht selten sein, da ja nicht nur die Erweiterungen die selben sein müßen, sondern auch genau die Versionen. Da kann sich schnell mal was ändern innerhalb von einem Tag. Muß also auch wieder überpfüft werden.
Ich glaube Ihr stellt euch manche Dinge etwas zu einfach vor. Wenn es so super einfache Lösungen geben würde, dann hätten da die Composer Leute sicher schon drann gedacht ;-)

Viele Grüße

PS: Ich muß zugeben, das ein Desktop-Tool sehr sehr verlockend klingt. Um dann auch Private Repros mit rein zu nehmen, müßte man diese dort auch einbinden können. Eventuell wäre sowas auch etwas für Version 2 von so einem Tool...Aber auch so etwas will irgendwie finanziert werden könnte ich mir denken. Ist ja doch recht aufwändig für 3 OS sowas zu machen.

[Toflar]

Um zu wissen, was sich geändert hat, müssen zuerst die Abhängigkeiten aufgelöst werden ;-) Bzgl. der privaten Repositories: Wer fähig ist, private Repositories zu nutzen, ist auch fähig Composer lokal auf der Kommandozeile zu bedienen. Ist ja nicht so als wäre das ein Hexenwerk.

[FloB]

Dieses Abhängigkeitenproblem (inkl. Voroptimierung anhand bekannter Abhängigkeitsbäume) kann man nur mit einem Haufen mathematischer Theorie lösen, da mangelt es leider vielen Programmierern an der nötigen Ausbildung in (höherer) Mathematik. Und selbst wenn das Problem mathematisch gelöst ist, müsstest du das erstmal in PHP umsetzen . (Bin per Zufall grade über folgenden Artikel gestoßen, der gibt einen vereinfachten Vorgeschmack auf die Problematik, auch wenn er mit dem aktuellen Thema gar nicht direkt was zu tun hat: http://www.toptal.com/machine-learni...a-tree-kernels)

PS: Ich muß zugeben, das ein Desktop-Tool sehr sehr verlockend klingt. Um dann auch Private Repros mit rein zu nehmen, müßte man diese dort auch einbinden können. Eventuell wäre sowas auch etwas für Version 2 von so einem Tool...Aber auch so etwas will irgendwie finanziert werden könnte ich mir denken. Ist ja doch recht aufwändig für 3 OS sowas zu machen.

Naja für OS X und Linux reicht im Prinzip ein Bash-Script, das könnte man sogar in PowerShell portieren. Aber die Kommandozeile ist ja nicht unbedingt für die Zielgruppe geeignet. Deswegen würde ich ein simples Web-Frontend basteln, was in Electron (https://dzone.com/articles/building-...-with-electron, https://www.npmjs.com/package/electron-packager) verpackt ist und die PHP-CLI (per child_process.spawn() oder einem fertigen Package*) aufruft – Daten per Copy&Paste oder Drag'N'Drop oben rein, unten kommt die composer.lock raus. Die App muss dann "nur" sicherstellen, dass PHP installiert ist (oder gleich mitliefern?) und Composer mitliefern bzw. herunterladen.

Langfristig könnte das Tool sogar mit einer API im Contao-Composer-Plugin reden, um sich die benötigten Informationen zu ziehen und die fertige Datei direkt hochzuladen – dafür muss aber eine gute Rechteverwaltung bzw. Authentifizierung eingebaut werden.


* Auswahl an fertigen PHP-Packages für node/electron auf NPMjs.com:

• https://github.com/tomk79/node-php-bin
• https://github.com/sihorton/node-php-cgi
• https://github.com/cscott/node-php-embed
• https://github.com/iqbalfn/exec-php
• https://github.com/iqbalfn/run-php
• https://github.com/fgascon/node-require-php
• https://github.com/chr8993/php_server
• https://github.com/digplan/php-node
• https://github.com/fnobi/php-express
• https://github.com/alangecker/express-php
• https://github.com/xinix-technology/pas bzw. https://github.com/reekoheek/pas-php
• mehr: https://www.npmjs.com/search?q=php

Vielleicht ist in dem Zusammenhang auch das interessant – hilft allerdings nicht beim GUI-Problem: https://moquet.net/blog/distributing-php-cli/

[webstar]

Was man bei der "Composer-as-a-Service" Gechichte auch berücksichtigen müsste, sind Abhängigkeiten der PHP-Version, ja sogar manchmal von PHP-Erweiterung. All dies kann ja als Abhängigkeit definiert werden. Wenn beispielsweise der Service mit PHP 7 läuft und der Webserver auf PHP 5.4 kann es zu ganz anderen Ergebnissen kommen.

[FloB]

Was man bei der "Composer-as-a-Service" Gechichte auch berücksichtigen müsste, sind Abhängigkeiten der PHP-Version, ja sogar manchmal von PHP-Erweiterung. All dies kann ja als Abhängigkeit definiert werden. Wenn beispielsweise der Service mit PHP 7 läuft und der Webserver auf PHP 5.4 kann es zu ganz anderen Ergebnissen kommen.

Guter Punkt. Kann man die PHP-Version, die Composer annimmt, irgendwie faken?

Sonst kann man natürlich (grade mit den fertigen Docker-Bibliotheken) sich "schnell" die richtige Version laden, aber das ist natürlich ein dicker Haufen Daten, die der Service-Server dann zu schlucken hat.

[xtra]

Guter Punkt. Kann man die PHP-Version, die Composer annimmt, irgendwie faken?

Sonst kann man natürlich (grade mit den fertigen Docker-Bibliotheken) sich "schnell" die richtige Version laden, aber das ist natürlich ein dicker Haufen Daten, die der Service-Server dann zu schlucken hat.

Wurde alles schon bedacht.

Man kann die platform requirements mitgeben.

[Toflar]

Hab ich doch schon 2x geschrieben, das kann meine Cloud auch schon

[Zwergenmeister]

Guten Morgen,

möchte auch gerne meinen Senf dazu beigeben mich hat es heute auch mit dem Composer erwischt. Und wir sind schon seit dem Anfang an keine Freunde.

Fatal error: Out of memory (allocated 84410368)

Habe 4 Contao Installationen bei 1und1 laufen mit einem älteren Vertrag Dual Unlimited

2 Systeme sind als Backup bzw als Entwicklung und 2 Systeme Live habe das Update von 3.5.6 auf 3.5.8 heute eingespielt und da nach wollte der composer Client kein Update auf 0.16.3 machen zuwenig Speicher!

Also mal am nächsten Backup System vor dem Update auf 3.5.8 den Composer aktualisiert von 0.16.2 auf 0.16.3 ohne Probleme :-) Dennach das Live update auf 3.5.8 durchgeführt und noch mal zum composer auf aktualisieren gedrückt und siehe da selbe Problem Out of Memory !

Jetzt hab ich aktuell 3 System erst den Composer aktualisiert und dann das Live update / das ist erstmal soweit ok mit 0.16.3 kann nur keine Aktualisierungen machen ! Lösung in Arbeit

Ein System bleibt grade bei 0.16.2 bis das upgrade bei 1und1 durch ist.

------
Meine Lösung habe den Vertrag erstmal upgraden lassen von Dual Unlimited auf UNLIMITED PRO 4GB ! Kostet das selbe und spare sogar noch hintenrum bei den Mail Postfächern...

Jetzt zu 1und1 und dem Out of Memory wie auf Seite 1 schon geschrieben sind keine 2 gb oder 4gb garantiert sondern die sind auf Prozesse aufgeteilt und die dürfen max 260MB beim 4GB Tarif haben.

Bitte kein Meckern 1und1 ist mist usw. mach mal geht es nicht anders ! Und ich kann den Unmut von Oben mit dem Composer auch bestätigen, geht mir nicht anders und das wird langsam auch ein Grund gegen Contao sowie auch die weiter Entwicklung von 4.-5.0 was auch wieder einiges an arbeit bedeutet !

Es gibt von Contao genug User die das nicht professional machen, weil sie auch andere Arbeit haben und sich immer weider mit solche neun Problemen auseinander setzen müssen, wie die composer Krankheit!

Sorry für den schlechten Ton aber bin genervt von dem Composer weil er mir heute 3 Stunden arbeit verursacht hat !!!

Gruß
Zwergenmeister

[lucina]

Allerdings verlierst Du dabei aus den Augen, dass es nicht Contao ist, durch das ein Problem vorhanden ist, sondern einzelne Hoster, die ihre Kunden bezüglich des Arbeitsspeichers - mit Verlaub - schlicht verscheissern.

Nahezu alle PHP-basierte Software wird in Zukunft Composer nutzen, und das ist auch gut so, weil ein funktionierendes Paketmanagement, das Voraussetzung für sichere, verlässliche, interoperable Weiterentwicklung ist, nur so implementiert werden kann.

Sicher sind dazu auch andere Workflows erforderlich, und man kann sich auch fragen, ob Systemupdates nun unbedingt auf einem System, das offen im Netz steht gefahren werden müssen oder nicht besser lokal, auf Maschinen mit ausreichenden Ressourcen ausgeführt werden sollten. Lösungen werden entwickelt werden.

Mir ist bewusst, dass dann irgendwann für Menschen, die Webentwicklung nicht professionell betreiben, das Ende der Fahnenstange erreicht sein kann. Ich empfinde das auch manchmal als unschön, aber ich denke, dass es nicht zu ändern sein wird, sorry.

Auf der anderen Seite bin ich ganz egoistisch und denke, dass nur Professionalisierung mein Geschäftsmodell sichern helfen kann. Ich glaube nicht, dass man in fünf Jahren noch von gebastelten Webseiten für den Bäcker an der Ecke leben kann. Ich glaube noch nicht einmal, dass es den Bäcker an der Ecke in fünf Jahren noch geben wird. Ich kann das schade finden (und empfinde das auch so), oder ich kann die Herausforderung annehmen, mich mit dem Einsatz moderner Werkzeuge vertraut machen und mir dabei auch die technischen Voraussetzungen schaffen. Shared Hosting bei United Internet wird nicht dazu gehören.

[VGT]

Mir ist bewusst, dass dann irgendwann für Menschen, die Webentwicklung nicht professionell betreiben, das Ende der Fahnenstange erreicht sein kann.

Mit dieser Ankündigung nimmst du mir zum 10. Geburtstag von TL/Contao aber fast den Mut. Liebe Entwickler und Programmierer denkt auch bitte weiterhin an den nicht-Profi und Hobby-Seitenersteller für Anwender ohne gefüllten Geldbeutel. Denn so hatte ich eigentlich Open Source verstanden, nicht das auf einmal aus dem Projekt ein Kommerz-Produkt wird. Ich würde gern noch die nächsten 10 Jahre bei Contao bleiben trotz der derzeitigen Composer-Ärgernisse.

[tab]

Bei der rasanten Entwicklung, die im Bereich Web-Programmierung und CMS stattfindet, bin ich mir nicht sicher, ob in 10 Jahren Contao überhaupt noch existiert und wenn doch, ob es dann noch PHP-basiert sein wird. 10 Jahre sind eine Ewigkeit in diesem Bereich. Schau 10 Jahre zurück und du erblickst den Geburtstag von Contao / TypoLight. Schau noch 10 weitere Jahre zurück, PHP war gerade geboren, ebenso wie Microsofts "Frontpage" und tatsächlich bald darauf auch die "CSS Level 1 Recommendation". Schau noch 10 Jahre weiter zurück und du siehst ... was auch immer, jedenfalls kein World Wide Web.

Wer will also wirklich realistisch prognostizieren, was in 10 Jahren sein wird? Wird es überhaupt noch "Websites" im klassischen Sinne geben oder wird alles von Facebook, Google & Co assimiliert? (Wir sind Google, Widerstand ist zwecklos!). Falls es daneben noch was Konkurrenzfähiges geben sollte, wie wird es aussehen? In welcher Sprache wird es programmiert werden? PHP? Ausschliessen kann ich es nicht, aber ich persönlich glaube nicht daran.

[servpoint]

...
Auf der anderen Seite bin ich ganz egoistisch und denke, dass nur Professionalisierung mein Geschäftsmodell sichern helfen kann. Ich glaube nicht, dass man in fünf Jahren noch von gebastelten Webseiten für den Bäcker an der Ecke leben kann. Ich glaube noch nicht einmal, dass es den Bäcker an der Ecke in fünf Jahren noch geben wird....

Hast du dich angesichts der momentanen Weltlage und der Aussichten schon gefragt ob deine oder meine Dienstleistungen noch notwendig sein werden?