Podczas uruchamiania composer diagnose
pojawia się następujący błąd:
Wczytane jest rozszerzenie xdebug, co może nieco spowolnić program Composer. Zalecane jest wyłączenie go podczas korzystania z Composera.
Jak mogę wyłączyć xdebug tylko wtedy, gdy używam Composera?
php
composer-php
xdebug
greg0ire
źródło
źródło
bin/bash
raczej niż/bin/sh
, ponieważ temu drugiemu nie podobało sięfunction
słowo kluczowe (Ubuntu 14.04 LTS).composer self-update
To polecenie wyłączy moduł PHP5 Xdebug dla CLI (a tym samym kompozytor):
Usuwa link symboliczny xdebug.ini z
/etc/php5/cli/conf.d/
Zasugerowano na http://blog.lorenzbausch.de/2015/02/10/php-disable-xdebug-for-cli/
Zauważ, że w przypadku Ubuntu 16.04 prawdopodobnie musisz go uruchomić w ten sposób:
źródło
alias xdebug-on='sudo php5enmod -s cli xdebug'
ialias xdebug-off='sudo php5dismod -s cli xdebug'
tak jest teraz łatwo włączyćxdebug-on
i wyłączyćxdebug-off
xdebug.Myślę, że nie ma opcji konfiguracji PHP, aby mógł ładować różne konfiguracje zgodnie z docelowym skryptem. Przynajmniej nie bez powielania plików .ini ...
Możesz jednak dodać te opcje podczas uruchamiania programu Composer z php:
-n
powie PHP, aby ignorował wszelkie pliki php.ini. Zapobiegnie to załadowaniu xdebug dla tej samej komendy.-d
options pozwala na dodanie dowolnej opcji (na przykład uaktywnij required_ext.so). Możesz użyć wielu-d
opcji. Oczywiście jest to opcjonalne, możesz tego nie potrzebować.Następnie możesz utworzyć alias, aby znów był słodki.
Typowe rozwiązanie (ponieważ kompozytor potrzebuje json):
greg0ire> moje rozwiązanie oparte na tym:
Wygląda brzydko (próbowałem i nie udało mi się tego zrobić z xargs), ale działa… Musiałem jednak wyłączyć niektóre rozszerzenia, w przeciwnym razie otrzymuję następujące ostrzeżenia:
źródło
-n
wczoraj i miałem problem, ponieważ brakowało miphar
rozszerzenia. Postaram się dodawać coraz więcej rozszerzeń, aż zadziała, myślę, że to dobre rozwiązanie. Jeśli chodzi o alias, mam już kilka aliasów zsh, których nie utrzymuję. Może spróbuję zamienić plik binarny na skrypt bash lub zobaczę, czy mogę skonfigurować aliasy.composer.json
, na przykład „ext-ldap”: „*”, lub po prostu w zależności od tego, co jest potrzebne, aby zadania po instalacji działały poprawnie … Gdyby tylko istniał sposób na umieszczenie rozszerzenia na czarnej liście…php -m
diagnose
, a ponieważTworząc alias, pominiesz ten
composer
xdebug
komunikat o błędzie.Po prostu dodaj tę linię do
~/.bash_aliases
swojego systemu i powinna działać bezbłędnie.Załaduj ponownie powłokę, aby udostępnić nowy alias
composer
.STOSOWANIE:
UWAGA:
Nie musisz koniecznie używać żadnego innego parametru.
W zależności od systemu możesz mieć
.bashrc
zamiast.bash_profile
.AKTUALIZACJA:
Jak @AlexanderKachkaev wspomina w komentarzach, nie warto dodawać parametru memory_limit w następujący sposób, aby uniknąć awarii w niektórych sytuacjach:
źródło
-n
Wyłącza opcjaPhar
przedłużenia więc może nie działać zcomposer.phar
alias composer="php -d memory_limit=-1 -n /usr/local/bin/composer"
Wymyśliłem odpowiedź, która działa całkiem nieźle na OSX i prawdopodobnie mogłaby zostać dostosowana do dowolnej wersji PHP, która ładuje swoje rozszerzenia przy użyciu pojedynczych plików .ini w "dodatkowym katalogu ini":
źródło
Zwykle tworzę skrypt powłoki na projekt, ponieważ każdy projekt ma inną wersję PHP. Jest w
/bin/
katalogu obokcomposer.phar
icomposer.json
i uruchomić go jak./bin/composer
w moim katalogu projektu.Wygląda to tak (dla php56)
Te
-d
opcje skutecznie wyłączyć xdebug. TaCOMPOSER_DISABLE_XDEBUG_WARN=1
część wyłącza ostrzeżenie o problemach z kompozytorem.Preferowane jest wyłączenie rozszerzenia xdebug (zobacz rozwiązywanie problemów z kompozytorem ), ale osobiście podoba mi się prostszy skrypt.
Niektóre czasy na moim komputerze: 2 Uruchom z xdebug i włączoną obsługą ini: 1m33
Uruchom z xdebug, ale ini-wyłączone: 0m19
Uruchom bez xdebug: 0m10
źródło
COMPOSER_DISABLE_XDEBUG_WARN=1
: jeśli pojawi się ostrzeżenie, oznacza to po prostu, że twój scrit nie działa. Definiowaniexdebug.remote_autostart
wydaje się bezużyteczne, jeśli zdalne debugowanie jest wyłączone.xdebug.remote_autostart
. O skuteczności skryptów: Composer sprawdza, czy rozszerzenie xdebug jest załadowane, a nie, czy faktycznie coś robi, spójrz na kod tutaj . Opcje ini działają dobrze w "zwykłych" skryptach php, ale znowu: nie wykonałem żadnych testów wydajności ...Jeśli używasz PHPStorm, najnowsza wersja (2016.2) zawiera funkcję włączania XDebug dla skryptów CLI na żądanie, co oznacza, że możesz po prostu wyłączyć XDebug globalnie na swoim komputerze deweloperskim. IDE włączy go w locie, gdy będzie to wymagane przez kod wewnątrz twoich projektów.
https://blog.jetbrains.com/phpstorm/2016/06/xdebug-on-demand-for-cli-php-scripts-in-phpstorm-2016-2-eap/
Musisz edytować preferencje interpreterów PHP, aby uwzględnić ścieżkę do XDebug, jak opisano w powiązanym artykule.
Wydaje mi się, że jest to idealne rozwiązanie, ponieważ zwykle chcę XDebug tylko wtedy, gdy jestem w IDE.
Jednak XDebug ma inne potencjalne zastosowania, gdy jesteś „offline”, np. Rozszerzone zrzuty stosu w dziennikach błędów, które można stracić, wyłączając go globalnie. Oczywiście nie powinieneś mieć włączonego XDebug w środowisku produkcyjnym, więc byłoby to ograniczone do przypadków użycia, takich jak testy beta lub automatyczne testowanie skryptów CLI w fazie rozwoju.
źródło
Zamiast mieszać się z tymczasowym włączaniem lub wyłączaniem modułu PHP, gdy możesz mieć współbieżne procesy korzystające z PHP (na przykład jako część potoku CI), możesz powiedzieć PHP, aby wskazał inny katalog ładowania modułu.
Chociaż jest to podobne do niektórych rozwiązań wymienionych powyżej, rozwiązuje to kilka przypadków skrajnych, co jest bardzo przydatne, gdy jest używane przez Jenkinsa lub innego uczestnika CI, który przeprowadza testy na tej samej maszynie jednocześnie.
Najłatwiej to zrobić, używając zmiennej środowiskowej
PHP_INI_SCAN_DIR
Używanie tego w skrypcie lub zadaniu kompilacji jest łatwe:
export PHP_INI_SCAN_DIR=/etc/php.d.noxdebug php composer install
Oczywiście najpierw chciałbyś przygotować /etc/php.d.noxdebug, robiąc coś takiego:
mkdir /etc/php.d.noxdebug cp /etc/php.d/* /etc/php.d.noxdebug rm /etc/php.d.noxdebug/xdebug.ini
Oznacza to, że masz środowisko podobne do starego środowiska php, z brakującym tylko jednym modułem. Oznacza to, że nie musisz się martwić koniecznością ładowania modułów phar / json, tak jak w przypadku rozwiązania php -n.
źródło
Wymyśliłem rozwiązanie dla instalatora Composera opartego na systemie Windows - powinno działać dla każdej instalacji Composera, po prostu tworzy kopię załadowanego pliku INI i komentuje rozszerzenie zend xdebug, a następnie ładuje ten plik konfiguracyjny po uruchomieniu kompozytora .
Otworzyłem problem, aby sprawdzić, czy chcieliby zintegrować tę zmianę:
https://github.com/composer/windows-setup/issues/58
Znajdziesz tam moje instrukcje i kod.
źródło
Jak wspomniano w odpowiedzi Joyce'a , ten problem nie istnieje już w najnowszej wersji Composera.
Dokumentacja Composera została zaktualizowana, aby to uwzględnić . Zawiera szczegółowe informacje, jak włączyć xdebug z Composerem (jeśli jest to wymagane).
Możesz zaktualizować swoją wersję Composera, korzystając z automatycznej aktualizacji .
Na moim Macu musiałem zrobić:
sudo php /opt/local/bin/composer self-update
Więcej szczegółów na ten temat w kontekście instalacji Homebrew PHP można znaleźć w tym numerze .
źródło
Bezpośrednia manipulacja konfiguracją PHP
Oto mój wkład oparty na instalacji PHP zainstalowanej przez Homebrew w systemie Mac OS X.
Jest to opakowanie skryptu powłoki, zaprojektowane do zapisywania jako plik wykonywalny w
/usr/local/bin/composer
, z binarnym Composer pod adresem/usr/local/bin/composer.phar
:teoria operacji
Skrypt opakowania:
Skrypt jest połączony z instalacją PHP 5.5 w systemie OS X / Homebrew. Ścieżki powinny być dostosowane do pracy z innymi wersjami PHP oraz układami katalogów innych systemów operacyjnych i menedżerów pakietów. Zauważ również, że niektóre wersje seda nie potrzebują argumentu pustego łańcucha po
-i
opcji.Caveat Utilitor
Skrypt jest prosty, ponieważ działa bezpośrednio na głównych plikach konfiguracyjnych PHP, jednak jest to również wada: Xdebug zostanie również wyłączony dla wszystkich skryptów wykonywanych jednocześnie z tym skryptem.
W moim środowisku programistycznym jest to akceptowalny kompromis, biorąc pod uwagę, że Composer jest uruchamiany ręcznie i tylko sporadycznie; Jednak możesz nie chcieć używać tej techniki, jeśli uruchamiasz Composer jako część automatycznego procesu wdrażania.
źródło
W większości przypadków nie potrzebujesz xdebug w trybie CLI. Jeśli jest to dla ciebie do przyjęcia, możesz inaczej skonfigurować cli i cgi.
Więc jeśli utworzysz php-cli.ini i conf-cli.d w pobliżu wyjścia z pliku php.ini, możesz inaczej skonfigurować cli i cgi (dla cgi będą to php.ini i conf.d ). Po prostu nie umieszczaj xdebug.ini w pliku conf-cli.d.
źródło
Jeśli instalujesz narzędzie Composer za pomocą brew na OS X, możesz użyć tego aliasu:
źródło
Moim szybkim rozwiązaniem dla instalacji macports z wieloma wersjami PHP było napisanie tego prostego opakowania powłoki dla Composera:
Następnie uruchom dowolne polecenia kompozytora, takie jak:
Wady:
Nie eleganckie, ale proste.
źródło
$1…$7
… może to$@
lub coś takiego, będziesz musiał spojrzeć.Tworzenie aliasu dla kompozytora, aby wyłączyć xdebug i zapobiec błędom pamięci:
Dodaj tę linię do swojego ~ / .bash_profile
Uruchom ponownie terminal, aby udostępnić nowy alias.
źródło
Oto moje szybkie rozwiązanie, aby pozbyć się ostrzeżenia Xdebug w wersji PHP5-cli. Usunąłem obsługę Xdebug dla PHP5-cli w systemie Ubuntu 14.04.
Koniec z ostrzeżeniem Xdebug w PHP5-cli.
źródło
sudo phpdismod xdebug
byłby preferowaną metodą brutalnościrm