<p>Composer Hersteller/Paket neu installieren</p>

Nun, warum müssen Sie das Paket aktualisieren, wenn es dieselbe Version ist?

Die Versionsnummer wird nicht von Composer.json verarbeitet, wir aktualisieren diese Nummer über Jenkins, um die gesamte Pipeline verfolgen zu können.

In local ändert sich die Nummer also nie, sie ändert sich nur, wenn jemand festlegt, und Jenkins baut alles.

Nun, woher bekommt das Projekt das Paket? Etwas lokal oder von Jenkins generiert?

Das Projekt erhält das Paket lokal, während unserer Entwicklung und danach von Jenkins.

Und wenn wir lokal entwickeln, müssen wir natürlich ein bestimmtes Paket neu installieren, deshalb bitte ich um diese Verbesserung.

Es kann auch für einige Leute verwendet werden, die mit dem VCS arbeiten und ein Paket neu installieren möchten, nicht nur mit Artefakt.

Ich denke, es könnte für viele Leute nützlich sein, nur um ein Paket neu installieren zu können.

und vielleicht, wenn Sie versehentlich eine Datei/Dateien im Anbieter löschen und möchten, dass sie in den vorherigen Zustand zurückversetzt werden?

+1. Ich habe einen ähnlichen Workflow und es wäre großartig, einen Vorschlag dafür zu haben.

warum nicht rm -rf vendor && composer install

warum nicht rm -rf Vendor && Composer installieren

Nicht optimal, besonders wenn Sie viele Pakete haben.

Einfacher wäre
composer remove [vendor/package] && composer require [vendor/package]

Wäre gut zu haben
composer reinstall [vendor/package]

@milkovsky

Einfacher wäre
Composer entfernen [Lieferant/Paket] && Composer erfordern [Lieferant/Paket]

Wäre gut zu haben
Composer neu installieren [Anbieter/Paket]

Sie könnten jetzt rm -rf vendor/package && composer install tun, es wird genau das tun, was Sie wollen (vorausgesetzt, Sie haben die Sperrdatei).

+1 Neuinstallation wäre schön

+1 Neuinstallation
rm -rf .. && composer install ist umständlich

Wenn einige Dateien in Ihrem Bundle fehlen:
rm -rf Anbieter/"Anbietername"/
dann führe ein Composer-Update durch

Aber...
:+1: Verknüpfung zum Entfernen/Installieren neu installieren

+1 mehr :)

Ich arbeite lokal an einer Erweiterung. Ich nehme Änderungen daran vor, und keine der Änderungen ist aktiv, bis ich sie entferne und neu installiere. Dies ist ein langwieriger Prozess, der immer wieder wiederholt wird. Eine Neuinstallationsoption wäre sehr dankbar! Ich bin überrascht, dass diese Funktion noch nicht verfügbar ist und dass die Antwort hier "warum brauchen Sie sie" lautet. Es würde nur eine Minute dauern, diese Funktion in Composer hinzuzufügen, sie wird von vielen benötigt, und wenn Sie einen Schritt zurücktreten und darüber nachdenken, macht die Funktion einfach Sinn.

Außerdem denke ich, dass es eine Funktion geben muss, die Composer anweist, Dateien von woanders zu verwenden. So kann ich eine Bearbeitung vornehmen, und diese Bearbeitungen sind live, anstatt sie jedes Mal entfernen und neu installieren zu müssen. Echtzeitbearbeitungen würden die Arbeit mit Composer viel besser machen.

+1 siehe @WadeShuler

+1 für Neuinstallation

+1

IMHO selbst wenn Sie ein Paket neu installieren müssen, können Sie dafür einen einfachen Shell-Alias ​​erstellen.

@hkdobrev
Nun, wir könnten alle benutzerdefinierte Skripte für alles selbst erstellen, aber es ist immer besser, eine nativ unterstützte und gut getestete Funktion in dem Tool oder der Bibliothek zu haben, die Sie verwenden. Es ist keine gute Praxis, Probleme durch temporäre Problemumgehungen zu lösen, die in der nächsten Version des Tools möglicherweise veraltet sind.

Ein weiterer Punkt ist, dass der Benutzer sicher sein kann, dass die Neuinstallation das tut, wofür sie eigentlich erstellt wurde: Pakete neu installieren. Woher soll der Benutzer wissen, dass er das Paket im Herstellerverzeichnis löschen und neu installieren muss. Wie @AlexBaitov sagte:

rm -rf .. && Composer-Installation ist umständlich

Nie erwähnt, dass eine saubere Neuinstallation die Caches für das Paket, das Sie neu installieren möchten, möglicherweise ungültig macht. Warum haben andere Paketmanager wie apt-get das Flag für die Neuinstallation?

@P0rnflake Ich stimme dir

Ich habe dieses Ticket seit über einem Jahr erstellt, ich weiß, das hat nicht die Priorität.

Aber anstatt nach Alternativen oder selbstgemachten Übergangslösungen zu suchen, denke ich, dass dieses Ticket schon längst gelöst wäre.

Fast alle Tools haben das "--reinstall" Ich verstehe nicht, warum es eine Debatte darüber gibt.

Wenn Sie die Neuinstallation nicht durchführen möchten, schließen Sie einfach dieses Problem, ansonsten führen Sie eine "Neuinstallation" durch.

Mit bestem Gruß

Wenn Sie die Neuinstallation nicht durchführen möchten, schließen Sie einfach dieses Problem, ansonsten führen Sie eine "Neuinstallation" durch.

Wenn Sie es wirklich wollen, können Sie auch zu Composer beitragen. Wir alle arbeiten in unserer Freizeit am Komponisten

Ich denke, es wäre hilfreich, wenn wir das Problem als Verbesserung klassifizieren und es zu einer Art Meilenstein mit Priorität hinzufügen könnten.

Meiner Meinung nach ist der frustrierende Punkt, dass es eine endlose Diskussion gibt, ob und warum nicht, um Anstrengungen zu vermeiden.

Wenn es mit der Roadmap des Komponisten zu tun hat, würde es vielleicht einer von uns implementieren.

@P0rnflake Ich denke, Sie meinen diese Meilensteine ​​- https://github.com/composer/composer/milestones Ich persönlich würde es in Nizza stecken , aber die Betreuer von Composer würden das entscheiden.

@hkdobrev Ja, das meinte ich, bringe dieses Thema einfach offiziell "auf die Straße", damit die Mitwirkenden eine Motivation haben, daran zu arbeiten.

Okay, ich denke, ein --reinstall Flag macht nicht viel Sinn, da unser install-Befehl nicht wirklich ein bestimmtes Paket installiert. Ein reinstall Befehl, der einen oder mehrere Paketnamen verwendet, ist wahrscheinlich sinnvoller. Falls es jemand toll beisteuert, aber bitte in der Zwischenzeit nicht einfach :+1: hier schreiben, es hilft nicht, die Dinge schneller zu erledigen.

Ich stimme zu, dass ein Shell-Alias ​​eine Option ist, aber zuerst verlieren Sie 30 Minuten, suchen nach einer Neuinstallation, und dann zwingt Sie das Entfernen, die Datei composer.json zurückzusetzen und dann zu aktualisieren und dann neu zu installieren.

Wie wäre es einfach mit rm vendor/composer/installed.json ?

Wir würden auch so etwas brauchen. Unser Anwendungsfall ist, dass wir normalerweise dist-Pakete installieren, aber in vielen unserer Projekte arbeiten wir auch in _unseren_ Vendor-Erweiterungen, die für diese Angelegenheit git-repos (source) sein sollten.

Daher verwenden wir derzeit auch rm -rm vendor/ns1 vendor/ns2 && composer install --prefer-source . Der Nachteil ist, dass Sie manuell überprüfen müssen, ob bereits Änderungen im Code vorgenommen wurden. Composer dh warnt Sie, wenn ein Source-Repo Änderungen hat - was sehr nützlich ist.

Wie wäre es mit einer Option extra , um die bevorzugte Strategie zu definieren?

{
  "extra": {
     "prefer-source": {
        "ns1/*",
        "ns2/a-package"  
     }
  }
}

Wie wäre es mit.. einem Ausflug in die Dokumentation? :) https://getcomposer.org/doc/06-config.md#preferred -install

Composer kann Sie auch nicht vor Änderungen in dist-Paketen warnen, daher würde eine Neuinstallation dort nichts helfen.

@Seldaek Danke :) Ich dachte, ich hätte das "irgendwo" gesehen.

Nur eine Frage: Eine Befehlszeilenoption --prefer-source nur dann Vorrang, wenn das Paket als auto konfiguriert ist? Andernfalls gewinnt der Wert in config ?

@schmunk42 Ich denke, der Wert in der Befehlszeile hat immer Vorrang. Auf diese Weise können Sie die Installation bevorzugt in der Konfiguration vornehmen, aber in der Produktion immer mit --prefer-dist installieren.

Hier ist mein Anwendungsfall:

Während der Entwicklung einer Anwendung wird das Repository eines Pakets zu repositories hinzugefügt, um die Entwicklungszyklen zu beschleunigen. Aber dies fügt die dist Info nicht zur Composer.lock-Datei hinzu.

Wenn nichts dagegen unternommen wird, wird dieses Paket während der Bereitstellung immer geklont, was mehr Zeit und Platz in Anspruch nimmt. Ich bräuchte also eine Möglichkeit, die dist Informationen für ein Paket zu aktualisieren.

Leider kann ich dies nicht wirklich ohne Anstrengung tun. Das Löschen des gesamten vendor Verzeichnisses gefolgt von composer install --prefer-dist wird dieses Paket trotzdem klonen, da dist Informationen nicht aufgezeichnet wurden, selbst wenn das vcs-Repository entfernt wurde.

Ich möchte die Dist-Informationen für ein bestimmtes Paket hinzufügen, das in einer markierten Version als geklontes Repository installiert ist.

Ich muss das alles machen:

1. Vorausgesetzt, die Anwendung ist ausgecheckt und Abhängigkeiten wurden installiert/geklont.
2. Entfernen Sie den Repository-Eintrag
3. Entfernen Sie den genauen Ordner in vendor dieses Pakets.
4. Führen Sie composer update .

Der negative Nebeneffekt: Alle Abhängigkeiten werden aktualisiert.

Das Problem im Inneren: Woher weiß ich den Paketnamen des Repositorys, das ich entfernen muss?

Wenn ich dies automatisch per Skript tun möchte, müsste ich alle Herstellerordner scannen, diejenigen finden, die geklonte Repositorys sind, dann git remote -v ausführen, um die URL zu erhalten, und dann auch die composer.json analysieren.

Jetzt kann ich den Ordner entfernen und composer update vendor/package ausführen, um nur dieses Paket selektiv zu aktualisieren, aber ich habe immer noch ein Update.

Was ich stattdessen lieber machen würde:

1. Vorausgesetzt, die Anwendung ist ausgecheckt und Abhängigkeiten wurden installiert/geklont.
2. Entfernen Sie den Repository-Eintrag
3. Führen Sie composer reinstall --prefer-dist .

Und Komponist würde versuchen , die genaue Version bereits installiert zu finden, und wenn die Informationsquelle (packagist.org oder lokale Instanzen) verursacht eine dist Lage, würde es es für die gesperrte Datei und Swap hinzufügen von geklonten zu zip- installierten Herstellerordner für dieses Paket.

Etwas, das nahe kommt, ist, dass, WENN ich den Herstellerordner dieses Pakets gelöscht habe, das Ausführen von composer update --lock die dist-Version installiert und die dist Informationen in die Sperrdatei einfügt. Aber ich muss noch herausfinden, welcher Ordner gelöscht werden soll, wenn ich minimale Dateioperationen möchte.

TL; DR:
Was ich festgestellt habe, funktioniert ohne unbeabsichtigte Updates:

1. Vorausgesetzt, die Anwendung ist ausgecheckt und Abhängigkeiten wurden installiert/geklont.
2. Entfernen Sie den Repository-Eintrag
3. Entfernen Sie alle Anbieterordner.
4. Führen Sie composer update --lock .

Dadurch werden alle Pakete erneut installiert (höchstwahrscheinlich aus dem Cache), Pakete, die zuvor geklont wurden (aufgrund des direkten vcs-Repository-Links) explizit als ZIP-Downloads installiert und auch die vollständigen dist Informationen in die Sperrdatei eingefügt .

Für meinen Anwendungsfall besteht die minimale Lücke zwischen dem, was vorhanden ist und dem, was fehlt, darin, dass der vorgeschlagene reinstall Befehl wie update --lock fungieren sollte, nachdem er den Vendor-Ordner geleert hat. Bonuspunkte für das Weglassen unnötiger Dateioperationen - die einzige offensichtliche Operation hier wäre der Wechsel von source zu dist für die Pakete, die dies unterstützen können.

Wenn Sie Bibliotheken in Composer-Projekten erstellen, verwenden Sie zunächst dev-[branch]-Versionen. Nach dem Wechsel zu getaggten Versionsnummern, zB 1.0.0, gibt es jedoch eine Zeit, in der es in den frühen Tagen des Bibliothekspakets noch viele Point-Releases gibt.

Das Problem, das ich habe, ist, dass es in diesen frühen Tagen (und sogar später) einfach ist, einen Bibliothekscode zu ändern, um einen Fix zu untersuchen, und bevor Sie es wissen, haben Sie Änderungen in 6 verschiedenen Dateien vorgenommen, damit der Fix funktioniert. An dieser Stelle stellen Sie fest, dass Sie vergessen haben, den Projektordner im Vendor zu entfernen und --prefer-source auszuführen. Jetzt haben Sie also Änderungen in vielen Dateien und keine Möglichkeit, diese Änderungen aufzulisten (kein Git-Diff) und keine Möglichkeit, sie erneut anzuwenden.

Für mich wäre es besser, anstelle von --reinstall etwas zu haben, um genau diesen Workflow zu verwalten. Da ich denke, dass es den Ordner tatsächlich auf eine Seite verschieben muss, den Klon durchführen und dann die Dateien wieder überlagern, damit die Änderungen erhalten bleiben und zum Commit bereit sind. Dies ist, was ich in den meisten Fällen mache, ich verschiebe den Ordner, Composer update --prefer-source, verschiebe die Dateien zurück.

Dies setzt natürlich auch voraus, dass die jetzt geklonte Version genau dieselbe Version ist, auf der Sie zuvor waren. es müsste die Versionsnummer der Sperrdatei verwenden, sonst würden die geänderten Dateien, die es zu bewahren versucht, das Projekt aus den Fugen bringen, wenn es sich um eine alte Version handelt.

Vielleicht ist das besser als neuer Composer-Befehl?

Was ist mit composer prepare-fix vendor/project ?

@acuthbert sieht so aus, als ob Sie einen Blick auf https://getcomposer.org/doc/06-config.md#preferred -install werfen und auf source setzen sollten, wenn Sie immer Source wollen.

+1 für Neuinstallation

Löschen Sie den Ordner und fordern Sie die Abhängigkeit an:

rm -Rf vendor/a/package && composer require a/package

Ein häufiger Anwendungsfall für mich ist: Ich finde eine Bibliothek in meinem Projekt, die sich schlecht benimmt, gehe zu ihrer Quelle und hacke schnell etwas, damit es funktioniert.
Dann kopiere ich den Hack in das Override-Verzeichnis meines Projekts, gehe ihn noch einmal durch, um meinen Hack zu verbessern, um ihn allgemeiner und PR-fähiger zu machen.
Jetzt möchte ich die Bibliothek in ihren ursprünglichen Zustand zurückversetzen, um zu wissen, dass der Hack vor dem Ursprung geladen wird. Okay, ich weiß, ich hätte den Hack wahrscheinlich früher kopieren sollen, aber das Einrichten von Override ist keine gute Idee, bis Sie sicher sind, dass es überhaupt behoben werden kann.
Eine einfache Installation --reinstall oder ein gleichwertiger Befehl würde mein Leben erheblich vereinfachen. Und nicht nur meiner.

Zusätzlich zum Argument von @AnrDaemon wäre es ideal, ein Paket unter Berücksichtigung des .git-Ordners neu installieren zu können, dh --prefer-source vs --prefer-dist .

+1

Ich bin kürzlich in einer Situation ausgeführt worden, in der ich den Befehl rm nicht verwenden konnte, aber composer ausführen konnte. Am Ende musste ich ein PHP-Skript schreiben, um ein Repository vom Anbieter zu löschen, und dann Composer install ausführen. Obwohl dies eine Notsituation war, wäre es viel schneller, einfach composer reinstall abc/package auszuführen.

+1

Eine weitere Überlegung ist , dass , wenn sie mit Installer Plugins arbeiten, können Sie Pakete oft an verschiedenen Orten installiert werden, und um sich daran zu erinnern , welches Paket installiert wurde , wo, so dass Sie rm path/to/vendor/package kann sehr mühsam sein, da eine solche erneute Installation Befehl mit, auch Wenn es nur darum geht, das Verzeichnis und den Pfad aufzulösen und den Inhalt zu entfernen, dann ist die effektive Ausführung von composer install einfach genug und kann Arbeitsabläufe erheblich vereinfachen. Da ich diese Funktionalität für einen bestimmten Anwendungsfall benötigte, habe ich ein Plugin implementiert, das einen composer reinstall Befehl bereitstellt. Die Details finden Sie im Paket roygoldman/composer-reinstall .

@roygoldman guter Punkt

Übrigens, in 1 Monat und 3 Tagen ist der Jahrestag der Erstellung dieses Beitrags (jetzt 5 Jahre, die Zeit verfliegt). Was denken Sie, um uns allen ein besonderes Geschenk zu machen, indem Sie die Neuinstallationsoption hinzufügen?

@roygoldman Ich habe jedoch eine Frage. Wie erkennt Ihr Plugin, wie ein bestimmtes Paket deinstalliert wird?

@AnrDaemon , die Verwendung des Plugins ist in seiner Readme detailliert beschrieben . Der Befehl ermöglicht die Übergabe eines oder mehrerer Paketnamen, composer reinstall vendor/package [vendor2/otherpackage ...] . Die Dateien für die angegebenen Pakete werden gelöscht und dann wird das Composer-Installationsprogramm ausgeführt, um die Versionen basierend auf der Sperrdatei erneut herunterzuladen.

Zu Ihrer großen Überraschung habe ich diese README zweimal gelesen, bevor ich meine Frage gestellt habe.
Es spricht ausführlich über die Paketinstallation, aber kein einziges Wort über die vorherige Paketentfernung.

Dann bin ich in deiner Frage etwas unklar. Das Projekt deinstalliert das Projekt nicht (im Sinne des Komponisten), es löscht nur die Dateien des Pakets und lädt die jetzt fehlenden Pakete erneut herunter. Die Pakete müssen vor der Ausführung nicht entfernt werden, das übernimmt der Befehl.

Wenn Sie sich bei der Projektnutzung immer noch nicht sicher sind, öffnen Sie bitte

Oh, es wird also nur davon ausgegangen, dass sich die Paketdateien alle im selben Verzeichnis befinden? Ich habs.

Ja, es wird davon ausgegangen, dass die Dateien alle in ein einziges Verzeichnis heruntergeladen wurden. Wenn es einen anderen allgemeinen Anwendungsfall gibt, den wir berücksichtigen sollten, und eine Möglichkeit, Dateispeicherorte programmgesteuert zu bestimmen, berücksichtige ich dies gerne in der Entfernungslogik.

+1 auch von mir. Es ist zB mit apt so praktisch, dass Sie einfach "apt install --reinstall" ausführen können, wenn Sie einige Dateien in Ihrem Paket beschädigt haben. Und ein Entfernen/Anfordern-Paar ist nicht äquivalent, da das Entfernen möglicherweise Abhängigkeiten entfernt oder nicht einmal möglich ist. Es wäre wirklich großartig, wenn es eine einfache Möglichkeit gäbe, einige Dateien, die Sie geändert haben, in ihren ursprünglichen Zustand zurückzusetzen.

Normalerweise funktioniert das Entfernen der Bibliothek und dann composer install gut. Aber in meinem Fall möchte ich vimeo/psalm neu installieren. Psalm hat eine files Autoload-Konfiguration, und wenn ich sie entferne, gibt Composer einen Fehler aus, da die Dateien in vendor/vimeo/psalm nicht mehr zum Laden gefunden werden können. Diese Pfade werden in vendor/composer Autoload-Dateien gespeichert und werden nicht entfernt, wenn Sie nur eine Bibliothek löschen. Dieses Problem würde sich für jedes Paket manifestieren, das Dateien explizit "auto" lädt.

@zainengineer hat die perfekte Lösung gegeben (Nachtrag: für mich, der nach einer langen Debug-Sitzung einfach alles neu installieren möchte):

Wie wäre es, einfach vendor/composer/installed.json löschen?

https://github.com/composer/composer/issues/3112#issuecomment -218937369

@ytsurk Interessante Definition von "perfekt". Bei diesem Fehler geht es darum, eine einfache Methode zur Neuinstallation eines einzelnen Pakets zu haben. Zumindest dachte ich, dass es hier darum geht.

Das stimmt, es ist nicht perfekt für ein Paket. Trotzdem kann die Zeile des gewünschten Pakets in _installed.json_ entfernt werden, und composer install installiert es erneut. Was, ich gebe zu, keine einfache Methode ist.. aber ich wollte es in diesem Thread sichtbarer machen.