Мы уже обсуждали лучшие практики Composer, и я всегда рекомендовал использовать composer global require при установке пакетов, которые можно использовать в нескольких проектах, особенно в инструментах командной строки. Затем на днях я столкнулся с этой дискуссией .
Суть в том, что большинство людей теперь считают, что global require — это плохая практика, если только глобально установленный пакет не имеет нулевых зависимостей. Технически это имеет смысл, когда кто-то использует одну среду для всех своих проектов , но, как я прокомментировал в этом обсуждении, при использовании виртуальной машины для каждого проекта или правильно изолированной среды, такой как Docker и т. П., Эта проблема буквально спорна и global не может причинить вред.
ОП предлагает решение этой проблемы:
В качестве альтернативы пользователи должны использовать composer require для установки каждого инструмента командной строки в свой собственный локальный проект и вручную управлять своими
$PATHили двоичными файлами (например, путем создания символических ссылок из каталога bin, уже находящегося в$PATH).
Для меня это совершенно неприемлемое осложнение. Composer был гордостью PHP за то, насколько им было легко пользоваться и насколько он новичок в управлении пакетами — локальном или глобальном. Необходимость символической ссылки (особенно с учетом несимвольных ОС, таких как Windows) привела бы к утомлению. Затем OP идет дальше, предлагая изменить способ работы global команды:
«глобальный», но изолированный проект может быть установлен в ~ / .composer / global / [что-то]; его каталоги vendor и bin отображаются в их обычном расположении, а содержимое каталога ~ / .composer / global / [что-то] / bin может быть зеркально отражено (через символическую ссылку) в ~ / .composer / vendor / bin или, возможно, лучшим вариантом будет просто ~ / .composer / bin. Существуют различные способы выбора строки [что-то]; самым простым будет просто org / project (хотя это означает, что существуют длинные пути, такие как ~ / .composer / global / org / project / vendor / org / project).
Я полностью согласен с этим подходом, и он кажется лучшим в обоих мирах. Очевидно, что это может вызвать некоторые проблемы с обратной совместимостью, но это не означает, что это не может произойти в версии 2.0 Composer. Тейлор Отвелл поддерживает это мнение чуть ниже:
Полностью согласен. Было бы удивительно, чтобы каждый глобально установленный пакет composer устанавливался в свой собственный изолированный каталог со своими изолированными зависимостями, а не конфликтовал бы с другими глобально установленными пакетами.
Следуя всему этому, в духе открытого исходного кода, OP затем создал альтернативную global реализацию в качестве отдельного инструмента: cgr . Давайте посмотрим, как это работает.
CGR — Composer Global требует альтернативы
Я буду выполнять все приведенные ниже команды на экземпляре Homestead Improved
Чтобы начать использовать CGR, мы устанавливаем его как глобальный пакет .
composer global require consolidation/cgr
Если папка bin вашего Composer отсутствует в переменной PATH, добавьте ее:
echo "export PATH=\$PATH:\$HOME/.composer/vendor/bin/" >> ~/.bashrc echo "export CGR_BIN_DIR=\$HOME/.composer/vendor/bin" >> ~/.bashrc source ~/.bashrc
Вышеприведенные команды расширяют $PATH . переменная с маршрутом к глобальному каталогу bin Composer (расположение по умолчанию в Homestead Improved — ваше может отличаться). Вторая команда настраивает каталог bin для использования cgr , а третья загружает эти изменения. Они также будут автоматически загружаться при каждом запуске интерфейса терминала от имени этого пользователя (в моем случае Vagrant через vagrant ssh ).
Затем CGR должен быть доступен, просто запустив cgr , и должен вывести общий файл справки Composer.
Установка глобального пакета Composer правильным способом
cgr phpunit/phpunit
В Homestead Improved есть полезный псевдоним, настроенный так, что ввод phpunit расширяется до vendor/bin/phpunit что удобно, когда phpunit установлен для каждого проекта, поэтому его можно запустить из корневой папки. Чтобы протестировать глобальную установку PhpUnit, нам нужно сначала удалить этот псевдоним (в ~/.bash_aliases прокомментировать соответствующую строку), а затем выйти из оболочки и снова войти, чтобы псевдонимы перезагрузились. Затем, запуск этого недавно установленного в глобальном масштабе PhpUnit с выводом версии должен дать что-то вроде:
vagrant@homestead:~$ phpunit --version PHPUnit 5.4.2 by Sebastian Bergmann and contributors.
Теперь давайте попробуем установить два несовместимых пакета.
cgr laravel/installer cgr wp-cli/wp-cli
Конечно же, они оба хорошо установлены. Давайте проверим, работают ли они.
vagrant@homestead:~$ wp --version WP-CLI 0.23.1 vagrant@homestead:~$ laravel --version Laravel Installer version 1.3.2
Все хорошо! Глобальные пакеты, которые ранее конфликтовали из-за несоответствия в зависимостях, теперь могут сосуществовать бок о бок и использоваться для всей ОС без помех!
Что НЕ должен делать инструмент?
В некоторых случаях вы можете установить плагины Composer. Как говорится в части ограничений , из-за того, что CGR устанавливает каждый глобальный пакет в свою собственную папку со своим собственным деревом зависимостей, они не будут доступны глобально во всех глобальных проектах. Таким образом, если вы хотите установить плагины, которые изменяют общее поведение композитора, вы все равно должны использовать composer global require вместо cgr . Например, сам CGR является одним из таких плагинов.
Что дальше?
Тест, тест, тест! Если вы часто пользуетесь global require командой global require , я призываю вас протестировать этот новый инструмент и дать Грегу Андерсону некоторую обратную связь о том, насколько хорошо он удовлетворяет ваши глобальные потребности и что можно улучшить, если что-нибудь.
Обратите внимание, что этот инструмент все еще является лишь проверкой концепции, и его реализация может быть переименована, переупакована, внедрена в ядро Composer или нет, и т.д. Другими словами, используйте ее как можно чаще, но не увеличивайте ее. пока слишком сильно зависеть от этого.
Пока ваши глобальные пакеты устанавливаются, почему бы не рассказать нам, как вы относитесь к composer global require ? Это так же вредно, как многие сейчас думают, или это просто вопрос осторожности и наличия изолированных сред разработки? Что-то другое? Перезвон внизу!