Composer для самых маленьких

А действительно ли вы знаете где находится .lock файл ?

Некоторое время назад я узнал, что проект OpenCFP не хранит файл в репозитории. «Ну и что?!» — скажете вы, — “просто запускаем и всё отлично. У нас установятся те же зависимости, верно?”

Нет. Не верно.

Предназначение .lock файла — записать в него непосредственно те версии, которые были установлены и под которые велась разработка и тестирование, чтобы в дальнейшем можно было их переустановить. Это означает, что если у вас в указана версия , а ваш коллега запустил , которая установила и закоммитил файл , то вы, запустив , получите ту же 1.2.4, даже если 1.3.0 уже вышла. Это позволяет быть уверенным, что каждый, кто работает над вашим проектом будет иметь абсолютно одинаковые версии пакетов.

Теперь вы может быть подумали: при надлежащем семантическом версионировании версия 1.3.0 (или даже 1.2.5) должна быть обратно совместимой, т.к. всё ещё удовлетворяет указанному значению и major-ная версия не изменилась. В чём же заключается сакраментальная мысль ?

Что ж, пока вы не делаете код-ревью каждой новой версии используемых вами зависимостей, и их зависимостей, и зависимостей зависимостей… и т.д. и т.п., то остаётся высокая вероятность того, что какой-нибудь закравшийся баг поломает ваше приложение. В конце концов, все мы люди.

Ещё достаточно рапространённая практика для проектов ставить в зависимостях ссылку на dev-master, что позволяет всегда иметь самые последние изменения. Это означает, что при каждом запуске , но без сохранённого lock файла, composer будет устанавливать самый последний код библиотек, который будет напрямую с-pull-ен из их репозиториев.

Опять же, это проблема, если вы беспокоитесь о взломе вашего кода

И  это одна из причин почему важно представлять Composer сфокусированным вокруг файла. Это некое устройство безопасности и должно использоваться как таковое

Проблема неправильного именования классов

Если в проекте случайно 2 класса назвали одинаковым именем (включая неймспейс) и пока что ничего не поломалось, то Вам повезло, срочно переименовывайте неправильно названный класс. Потому, что в зависимости от файловой системы, composer может прочитать и составить маппинг по-разному, наглядный пример файла autoload_classmap.php на тестовом сервере:

а теперь пример этого же файла autoload_classmap.php на своей локальной машине:

Возможно разное поведение вызвано немного разными версиями PHP или разными файловыми системами, н в итоге, проблема автору известная и сейчас в таких случаях composer выдает предупреждения:

Мне кажется всего лишь показывать «Warning: Ambiguous class resolution» плохое решение, я бы сразу завершал работу composer-а с ошибкой, потому что из-за такой мелочи лично я на тестовом стенде убил 4 часа, а представляете что такое возникло на проде, нее, так нельзя. Казалось бы, откуда 4 часа трудозатрат, а оттуда, что все работает корректно, потому, что даже методы в данных классах называются одинаково (get_list) отличается только результат, в одном случае это список заказов, в др. случае это пустой список.

Разделы

FTP

  • Общие сведения
  • Решение проблем
  • Подключение по FTP через FileZilla
  • Подключение по FTP через Total Commander
  • Подключение по SFTP через WinSCP

Веб-приложения

  • Общие сведения по установке приложений (виртуальное окружение Docker)
  • PHP
  • Node.js
  • Ruby
  • Perl
  • Python
  • Установка PHP-фреймворков
  • Инструкция по установке composer

Домены

  • Как перенести домены в зонах .RU и .РФ к регистратору Beget
  • Как изменить сведения об администраторе домена .RU/.РФ/.SU
  • Как продлить доменное имя через Beget
  • Аннулирование доменного имени в зоне .RU/.РФ для которого Beget является регистратором
  • Изменение NS-серверов для доменного имени
  • Передача права администрирования доменного имени .RU/.РФ/.SU и международных зонах (Смена администратора домена)
  • Как перенести домены в Beget
  • Перенос доменов от регистратора Beget к другому регистратору
  • Разрешение споров о доменах
  • Инструкция по переносу доменов .RU/.РФ от Reg.ru на обслуживание к нам.

Другое

  • Полный бекап сайта через SSH
  • Основы работы с редактором VIM
  • Волшебный файл .htaccess
  • Примеры использования mod_rewrite
  • Установка GoogleAdsense и Яндекс.Директ
  • Подключение Google Analytics и Яндекс.Метрика
  • XDebug — дебаг и профилирование кода php (profiling)
  • Защита сайта от DDoS-атак
  • Мультисайтовость на движке Bitrix
  • Система защиты от DDOS атак — Syncookied
  • Восстановление сайта из резервной копии, сохранённой в корень аккаунта
  • Блокировка PHP сессий

Почта

  • Общие сведения
  • Решение проблем
  • Настройка DKIM
  • Настройка сервиса «Яндекс.Почта» для домена
  • Настройка Windows Live Mail
  • Настройка Microsoft Outlook
  • Настройка The Bat!
  • Настройка Mozilla Thunderbird
  • Настройка Mail на Mac OS X
  • Настройка почты на мобильных приложениях

Сайты

  • Неверное отображение домена в ссылках
  • Ошибка — Warning: Cannot modify header information…
  • Русификация Drupal
  • Сайт в неверной кодировке
  • Перенос сайта к нам
  • Как установить шаблон на CMS Joomla!
  • Как опубликовать сайт, созданный в Adobe Muse
  • Как добавить соответствие IP-адреса и домена сайта в файл /etc/hosts
  • Как сбросить пароль от панели управления сайтом в популярных CMS
  • Установка и настройка CPA-Tracker
  • Подключение SSL к сайту
  • Перенос сайта с аккаунта на аккаунт
  • Как экспортировать и импортировать базу данных Mysql

Сервисы

  • Настройка и использование Memcached
  • Использование Redis
  • Использование Sphinx
  • Подключение Sphinx к WordPress
  • Подключение Sphinx к Joomla
  • Настройка Sphinx в CMS Bitrix
  • Автоматический перенос сайтов

VPS

  • Перенос сайта c виртуального хостинга на VPS с помощью LAMP
  • Перенос сайта c виртуального хостинга на VPS c помощью Vesta
  • Выпуск и установка SSL-сертификатов от Let’s Encrypt на VPS

Command-line installation

To quickly install Composer in the current directory, run the following script in your terminal.
To automate the installation, use the guide on installing Composer programmatically.

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === 'e0012edf3e80b6978849f5eff0d4b4e4c79ff1609dd1e613307e16318854d24ae64f26d17af3ef0bf7cfb710ca74755a') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"

This installer script will simply check some settings,
warn you if they are set incorrectly, and then
download the latest in the current directory. The 4 lines above will, in order:

  • Download the installer to the current directory
  • Verify the installer SHA-384, which you can also cross-check here
  • Run the installer
  • Remove the installer

WARNING: Please do not redistribute the install code.
It will change with every version of the installer.
Instead, please link to this page or check how to install Composer programmatically.

Использование библиотек

Давайте для постов нашего блога начнем использовать Markdown-разметку. Сделать это с помощью подключенной нами библиотеки проще простого. Смотрим документацию на страничке пакета и просто повторяем для нашей ситуации.

Добавляем в модели статьи метод, который будет прогонять текст статьи через парсер, прежде чем его вернуть:

src/MyProject/Models/Articles/Article.php

Онлайн обучение PHP
Путь с полного нуля до джуниора!
Начать бесплатно

И добавляем вывод прошедшего парсинг текста в шаблоне:

templates/articles/view.php

Теперь при выводе статей содержимое поля text будет предварительно пропущено через markdown-парсер.

Пробуем создать новую статью, используя markdown-разметку.

Получаем на выходе отформатированный HTML-тегами текст.

Делаем то же самое для списка статей и вуаля – у нас блог, редактируемый с помощью markdown-разметки.

Определение уровня стабильности

Вернемся к ситуации описанной в начале статьи: приложение зависит от пакета , который зависит от пакета .

Корневой выглядит следующим образом:

{
    "require": {
        "A": "dev-master"
    }
}

При запуске Composer выполнит следующие шаги:

  1. Определит . Так как параметр не задан явно, то будет подставлено значение по умолчанию — .

  2. Зависимость требуется в версии . Благодаря префиксу Сomposer понимает, что уровень стабильности этого пакета . Так как зависимость описана в корневом пакете, пакет неявно получает флаг .

  3. Теперь когда пакет имеет версию , composer начинает его установку. Но пакет зависит от пакета , у которого требуемая версия тоже . Но так как зависимость описана не в корневом пакете, то пакет флаг не получает. Вместо этого наследует значение , которое в нашем случае равно .

    Таким образом пакет требуется в версии .

    Здесь все и ломается, так как версии в принципе существовать не может. Поэтому Composer и говорит, что не может найти пакет с требуемым уровнем стабильности.

Как работает Composer?

Нижеприведённая диаграмма показывает, как работает Composer при использовании Packagist в качестве центрального хранилища:

Если мы указываем, что хотим использовать различные репозитории, то Composer использует хранилище по умолчанию: Packagist. Composer запросит у Packagist информацию о всех пакетах, требуемых в файле , а также зависимостей, необходимых для этих пакетов.

Когда Composer получает всю информацию, он разрешает граф зависимостей, используя SAT solver и генерирует файл с конкретными пакетами, которые должны быть установлены для того, чтобы выполнить требования, запрашиваемые в файле . Наконец, Composer загружает эти пакеты из различных источников: GitHub, Bitbucket, PEAR или любого GIT/SVN/Mercurial репозитория.

Данная архитектура имеет несколько проблем: что произойдет, если Packagist упадет? Это не будет работать. Composer не сможет разрешить граф зависимостей. В дополнение к этой проблеме, что произойдет, если необходимые пакеты размещаются в GitHub’е, и он в настоящее время не работает? Это не будет работать. Пакеты не будут загружены, что повлияет на вашу разработку и выкладку.

Как мы можем минимизировать все эти проблемы? Добавлением резервирования. Мы можем создать наш собственный репозиторий с помощью Satis, используя это хранилище вместо (или в дополнение к) Packagist. Следующая диаграмма показывает ту же схему, но с использованием специального хранилища:

Теперь, Composer запрашивает информацию о необходимых пакетах в нашем индивидуальном хранилище и будет обращаться к Packagist только том случае, если наш репозиторий не имеет этой информации. Мы даже можем отключить Packagist и настроить наш репозиторий, чтобы все зависимости пакетов загружались в него. Кроме того, наше хранилище может загрузить пакеты и действовать в качестве reverse proxy сервера. Таким образом, мы больше не зависим от GitHub’а для загрузки пакетов.

3: Файл composer.json

Файл composer.json содержит информацию о зависимостях, которые должен скачать Composer для определённого проекта. Он позволяет задать необходимые версии зависимостей и исключить их нестабильные и потенциально опасные версии.

Этот файл не рекомендуется создавать вручную, поскольку при этом можно допустить ошибку в синтаксисе. Composer автоматически создаст файл composer.json после того, как вы добавите первую зависимость при помощи команды require. Остальные зависимости можно добавить с помощью этой же команды, и при этом нет необходимости вручную редактировать файл.

Процесс установки зависимостей проекта при помощи Composer состоит из следующих этапов:

  1. Определение необходимых приложению библиотек.
  2. Поиск подходящей открытой библиотеки в Packagist.org, официальном репозитории Composer.
  3. Выбор зависимостей.
  4. Запуск команды composer require, которая добавляет зависимости в файл composer.json и устанавливает пакеты.

Рассмотрим этот процесс на примере простого приложения.

Цель этого приложения — превратить заданное предложение в «понятный» URL (или slug); как правило, это приложение используется для преобразования названий страниц в URL-адреса (к примеру, обратите внимание на последний сегмент URL-адреса этого урока). Итак, создайте каталог проекта; для примера назовём его slugify:

Итак, создайте каталог проекта; для примера назовём его slugify:

Поиск пакетов на Packagist.org

Теперь попробуйте найти пакет, генерирующий slug-адреса, в репозитории Packagist.org. Просто  введите в поле поиска запрос slug.

Справа возле каждого результата поиска можно увидеть два счётчика. Первый показывает, сколько раз пакет был установлен; второй счётчик показывает, сколько раз пакет был отмечен на GitHub. Результат поиска можно переупорядочить согласно показателю одного из счётчиков. Конечно, пакеты с большим показателем счётчиков, как правило, более стабильны, так как они многими используются

Также важно проверить описание пакета – действительно ли это нужный пакет?

Итак, нужно найти простой конвертёр адресов. В руководстве используется пакет cocur/slugify.

Обратите внимание: Packagist указывает имя вендора и имя пакета (vendor name и package name). Каждому пакету присваивается уникальный идентификатор, или пространство имён (в том же формате, что и для репозиториев Github: vendor/package)

Необходимый пакет называется cocur/slugify. Чтобы загрузить пакет автоматически, нужно указать менеджеру зависимостей пространство имён пакета.

Запрос пакета

Итак, теперь точное имя пакета известно. Используйте команду composer require, чтобы добавить этот пакет в файл composer.json:

Как видите, Composer автоматически определяет необходимую версию пакета. Проверьте каталог проекта, теперь он содержит два файла (composer.json и composer.lock) и каталог vendor:

Файл composer.lock используется для хранения данных о версиях установленных пакетов и обеспечивает использование одинаковых версий пакетов в случае клонирования проекта. Каталог vendor содержит зависимости проекта.

Внимание: В случае использования контроля версий не отправляйте сообщения о коммитах каталога vendor; это применимо только для файлов composer.json и composer.lock. При установке проекта, который уже содержит файл composer.json, используйте следующую команду, чтобы установить зависимости проекта:

При установке проекта, который уже содержит файл composer.json, используйте следующую команду, чтобы установить зависимости проекта:

Ограничения версий

Файл composer.json содержит примерно такой код:

Обратите внимание на знак вставки (^) перед номером версии. Для определения версии пакета Composer может использовать несколько типов ограничений и форматов; эта функция позволяет следить за стабильностью проекта

Оператор ^ используется в файле composer.json для максимальной совместимости версий. В данном случае он определяет версию 2.13 как минимальную и разрешает обновления до версии 3.0.

В целом, вам не придётся особенно долго возиться с ограничениями версий в файле composer.json. Однако в некоторых ситуациях может потребоваться отредактировать ограничения вручную (например, если вышла новая версия библиотеки, но composer.json не разрешает обновиться до неё).

Эта таблица поможет разобраться в том, как работают ограничения версий Composer:

Примечание: Подробнее об ограничениях версий можно прочесть в документации программы.

Шаг 3 — Использование скрипта автозагрузки

Если вы дошли до этой части руководства, все последующее вам должно даваться очень легко. Ваши зависимости были установлены и ваш проект готов к работе. Почти.

Теперь вам необходимо загрузить эти зависимости в ваш PHP скрипт. Если бы не файл автозагрузки Composer, мы бы потратили довольно много времени. Файл находится в папке vendor вашего проекта. Вставка этого единственного файла в ваш PHP скрипт обеспечит видимость каждого пакета установленного для вашего проекта скрипту.

Чтобы добиться автозагрузки, просто напишите следующую строку перед объявлением или созданием любых новых переменных в вашем скрипте:

require 'vendor/autoload.php'

Пример скрипта ниже поможет вам лучше это понять:

require 'vendor/autoload.php'
PHP_Timer::start();
// ваш код
$time = PHP_Timer::stop();
var_dump($time);
print PHP_Timer::secondsToTimeString($time);

Запустите скрипт. В процессе выполнения он должен отображать результат подобный этому:

double(1.0967254638672E-5)
0 ms

Основные команды Composer

Разберем основные команды Composer для начинающих.

Если вы используете «composer.phar» локально, то приведённые команды необходимо соответственно изменить в зависимости от того как настроено ваше окружение.

Например, если файл «composer.phar» находится в текущем каталоге и интерпретатор php доступен без указания пути к нему, то установка пакета будет осуществляться так:

Установка пакета

Установка пакета через Composer осуществляется посредством выполнения следующей команды:

vendor — это имя поставщика php пакета, а package — это его название.

Например, добавление в проект пакета twig через composer будет осуществляться так:

Команда require не только загрузит требуемую библиотеку в проект, но и пропишет её ещё в файле «composer.json», т.е. обновит его. Если устанавливаемый пакет зависит от других библиотек, то они также будут установлены или обновлены. Кроме этого ещё будет обновлён файл «composer.lock».

Установка всех пакетов в проект

Установка сразу всех пакетов в проект осуществляется посредством команды:

Эта команда работает следующим образом:

  • проверяет, имеется ли файл «composer.lock»;
  • если файл «composer.lock» существует, то устанавливает версии, указанные в нём;
  • если файла «composer.lock» нет, то разрешает зависимости, описанные в файле «composer.json», создаёт файл «composer.lock» и устанавливает зависимости.

Обновление зависимостей

Команда для обновления установленных библиотек:

Эта команда обновит все зависимости установленные в проекте до последних версий (в соответствии с «composer.json») и файл «composer.lock».

Если необходимо обновить не все пакеты, а один или несколько, то их необходимо перечислить через пробел.

Команда для обновления одной библиотеки:

Удаление пакета

Команда Composer для удаления пакета из проекта:

Для удаления одновременно нескольких пакетов можете их перечислить через пробел:

Создать новый проект

Создание нового проекта из указанного пакета в текущую директорию выполняется так:

Создание нового проекта в указанную директорию выполняется так:

Получение подробной справки по команде

Вывод подробной справки по команде:

Например, вывести подробную инструкцию по использованию команды require можно следующим образом:

Файл конфигурации репозитория

Давайте представим, что мы являемся компанией с несколькими разработчиками и для наших проектов нужно только две зависимости: Symfony HttpFoundation component и Twig. Мы хотим, чтобы у нас был индивидуальный репозиторий со всеми версиями (за исключением версий разработки) этих двух пакетов и мы не должны полагаться на GitHub:

{
    "name": "ServerGrove repository",
    "homepage": "http://149.5.47.251:8001",
    "repositories": [
        {
            "type": "vcs",
            "url": "git@github.com:symfony/HttpFoundation.git"
        },
        {
            "type": "vcs",
            "url": "git@github.com:twigphp/Twig.git"
        }
    ],
    "require-all": true,
    "require-dependencies": true,
    "archive": {
        "directory": "dist",
        "format": "tar",
        "skip-dev": true
    }
}

Формат файла довольно прост, но давайте посмотрим, что каждое из полей значит:

  • : имя хранилища.
  • : URL репозитория.
  • : содержит список репозиториев, которые мы хотим отразить.
  • : скачать все пакеты, а не только те, что с тегом.
  • : если значение «true», Satis автоматически разрешает и добавляет все зависимости, поэтому Composer’у не нужно будет использовать Packagist.
  • : файлы будут храниться в каталоге и нам не нужно будет загружать пакеты.

Затем, мы говорим Satis создать хранилище:

$ ./bin/satis build satis.json servergrove-satis/

После этого, у нас есть новый каталог с названием , который содержит два файла: и . Первый является файлом конфигурации хранилища, который будет прочитан Composer’ом, чтобы определить, какие пакеты предлагает репозиторий. Файл — просто статический HTML файл с информацией о хранилище. Он также содержит каталог со всеми пакетами, поэтому они не будут больше загружеаться с GitHub’а.

И, наконец, мы публикуем наш репозиторий с помощью PHP-шного встроенного сервера (для реальных хранилищ рекомендуется использовать Apache или Nginx):

$ php -S localhost:8001 -t servergrove-satis/

Теперь, если мы перейдем к , мы должны увидеть что-то вроде этого:

Подключаем наш собственный Composer-пакет

Далее, подключим наш собственный пакет SuperLogger, который правильно оформлен, но опубликован не на packagist.org, а на github:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
    "require" {
        "php"">=5.3.0",
        "silex/silex""dev-master",
        "twig/twig"">=1.8,,
        "mycompany/superlogger""dev-master"
    },
    "repositories"
        {
            "type""git",
            "url""http://github.com/pqr/superlogger"
        }
    
}

Чтобы Composer знал где искать пакет «mycompany/superlogger», мы добавили массив repositories со ссылкой на соотвествующий github репозиторий

Обратим внимание, что записи в массиве repositories напрямую никак не связаны с блоком require — между пакетами и репозиториями не указано соответствие. На сколько я понял, Composer ищет все требуемые пакеты во всех указанных репозиториях (в т.ч

на сайте packagist.org) и скачивает найденные совпадения по каким-то внутренним приоритетам. Более глубоко я в этом моменте ещё не разбирался, поправьте меня, если кто-то знает детали.

Шаг 2 — Создание и общая информация о composer.json

Теперь перейдем к самой интересной части — первое использование Composer для вашего PHP проекта. Для этого, создайте отдельный файл composer.json. Этот файл служит своего рода шпаргалкой для Composer; он будет загружать для вашего проекта только те пакеты (зависимости), которые в нем упомянуты.

Обратите внимание, что он также проверяет совместимость версий пакетов для вашего проекта. К примеру, если вы используете старый пакет в вашем проекте, файл composer.json даст вам об этом знать для избежания возможных проблем в будущем

У вас есть возможность создавать и обновлять файл composer.json самостоятельно. Но так как это руководство показывает, как автоматизировать некоторые задачи, этот способ будет слегка неуместен.

Давайте продемонстрируем полезность composer.json создав образец проекта. Наш проект — это простой таймер PHP, позволяющий разработчикам узнать сколько времени тратиться на выполнение той или иной части кода. Это очень полезно при оптимизации и отладке. Следуйте данным этапам для создания своего проекта:

  1. Создайте новую папку для проекта. Так как наш проект это таймер, мы назовем его немного неоригинально, phptimer. Для этого впишите эту команду:
mkdir phptimer
  1. Войдите в созданную папку с помощью команды:
cd phptimer
  1. Теперь вам нужен пакет или библиотека с уже реализованным в нем таймером PHP. Лучшее место для поиска пакетов это Packagist – официальное хранилище пакетов созданных для Composer. Здесь вы сможете найти все виды библиотек для облегчения вашей ноши разработчика. Для данного руководство нам понадобиться пакет или библиотека с таймером. Для этого впишите ‘timer’ в поисковое поле, как на картинке снизу:

Как вы видите на сайте имеется множество таймеров для разработчиков сайтов. Каждый пакет имеет свое имя и краткое описание. Напротив каждого из пакетов есть счетчик скачиваний, вместе со счетчиком звезд GitHub. Давайте скачаем phpunit/php-timer (7-ой в списке) так как у него больше всего скачиваний и звезд GitHub

Обратите внимание, что каждый из пакетов имеет следующий формат: поставщик/пакет [phpunit/php-timer]. Это также называют пространством имен. Оно должно быть уникальным для каждого из пакетов на Packagist, так как оно используется для определения различных пакетов.
После выбора пакета для установки, нам необходимо уведомить Composer о вашем выборе, чтобы он добавил его в ваш проект

Для этого впишите следующую команду в терминал:

composer require phpunit/php-timer

После выполнения команды, Composer создаст в папке вашего проекта два файла (composer.json и composer.lock), в дополнение к новой папке под названием vendor.

Папка vendor это то место, где Composer хранит все пакеты и зависимости. Это довольно удобно, если вы хотите скопировать все пакеты из одной системы на другую. Однако мы настоятельно не рекомендуем это делать, так как это потребует ручного обновления файла composer.json, уже не говоря о беспорядке к которому это может привести. Еще один совет для тех, кто использует VCS (систему контроля версий) вроде Git; не добавляйте файл vendor в ваш репозиторий.

Говоря о версиях пакета, после выполнения команды выше, вы увидите строку с данными о версии скачанного Composer пакета phpunit/php-timer. В нашем случае она выглядит так:

Using version ^1.0.9 for phpunit/php-timer

Знак вставки (^) определяется Composer, как опция ‘максимальной совместимости.’ Это означает, что когда этот знак появляется возле версии, Composer разрешит обновление пакета, если он конечно не приведет к ошибкам. В нашем случае, Composer позволит обновление в диапазоне >=1.0.9 версиях Composer, перейдите на страницу документации.

7 ответов

24

Лучший ответ

Это зависит от хоста, но вы, вероятно, просто не можете (вы не можете на моем общем хосте на Rackspace Cloud Sites — я спросил их).

Что вы можете сделать, так это настроить среду на вашем компьютере-разработчике, которая примерно соответствует вашему общему хосту, и сделать все ваше управление через локальную команду. Затем, когда все установлено (вы втягивали все зависимости, обновлялись, управлялись с помощью git и т.д.), Вы можете «нажимать» это на свой общий хост через FTP.

Ответ дал

03 янв. 2014, в 00:52
Поделиться

35

Этот учебник работал у меня, разрешая мои проблемы с разрешениями на /usr/local/bin и php-cli (какой композитор требует и может по-разному сглаживать общие хостинг).

Сначала запустите эти команды для загрузки и установки композитора:

Определите местоположение вашего php-cli (необходимо позже):

(Если это не удается, используйте )

Он должен вернуть путь, например /usr/bin/php -cli,/usr/php/54/usr/bin/php-cli и т.д.

edit ~/.bashrc и убедитесь, что эта строка находится наверху, добавив ее, если это не так:

а затем добавьте этот псевдоним внизу (используя путь php-cli, который вы определили ранее):

Завершите следующие команды:

Ответ дал

03 апр. 2015, в 18:37
Поделиться

21

Я успешно установил Composer (и Laravel) на моем общем хостинге только с FTP-доступом:

  • Загрузите и установите PHPShell на общем хостинге

  • В PHPShell добавьте пользователя и псевдоним:

  • Войдите в PHPShell и введите:

  • При успешной установке запустите Composer:

Ответ дал

09 окт. 2014, в 12:41
Поделиться

10

Вы можете сделать это следующим образом:

  • Создайте каталог, в который вы хотите установить композитор (пусть говорят /home/your _username/composer)
  • Перейдите в этот каталог —
  • Затем выполните следующую команду:

  • После этого, если вы хотите запустить композитор, вы можете сделать это таким образом (в этом случае вы должны находиться в каталоге композитора):

  • В качестве следующего шага вы можете сделать следующее:

    .

    И запустите команды, как обычно:

Надеюсь, что поможет

Ответ дал

18 нояб. 2015, в 20:08
Поделиться

6

Мне удалось установить композитор на хостинг HostGator. Войдите в систему SSH с помощью Putty, сразу после входа в систему вы должны находиться в своем домашнем каталоге, который обычно является /home/username, где имя пользователя — ваше имя пользователя. Затем выполнил команду завивки, отправленную @niutech выше. Это загрузило композитор в мой домашний каталог, и теперь он доступен и работает хорошо.

Ответ дал

18 апр. 2015, в 17:05
Поделиться

В большинстве случаев вы не можете — в зависимости от хоста. Вы можете связаться с группой поддержки, на которой подписан ваш хостинг, и если они подтвердят, что это действительно не разрешено, вы можете просто настроить композитор на своей машине dev и зафиксировать и направить все зависимости на ваш живой сервер, используя Git или что вы предпочитаете.

Ответ дал

12 июль 2016, в 06:33
Поделиться

Ещё вопросы

  • 200В чем разница между require и require-dev?
  • 133Каковы различия между PSR-0 и PSR-4?
  • 91Обновление PHP Composer «не удается выделить память» ошибка (с помощью Laravel 4)
  • 95Могу ли я установить Laravel без использования Composer?
  • 66Как установить Laravel 5.0
  • 55Laravel 5 класса «форма» не найден
  • 48Композитор: file_put_contents (./ composer.json): не удалось открыть поток: отказано в разрешении
  • 38Установка конкретной версии laravel с помощью composer create-project
  • 38Композитор: требуются пакеты с разными уровнями минимальной стабильности
  • 30композитор Laravel создать проект

Details

First you must choose the installation type. By default Composer will be installed to a
with a Control Panel uninstaller. You can choose Developer Mode if you want more control, which will install
Composer anywhere you want without an uninstaller.

The next step is to find the location of your , which is the PHP command line interpreter. The installer
searches common locations on your computer and presents you with its findings. If PHP is already in your path then it
will display this value. If not, or you want to choose a different PHP, you must select from the list or hunt around manually.

The installer will then check that PHP and your path are set up correctly. If it finds any errors it will give you
the chance to fix them. It will also offer to either create or modify the file if required settings do not exist. See for more information.

Next, the installer will ask if you need a proxy server to connect to the internet. If it finds any values in your
Internet Settings or your environment, then the proxy url will be displayed.

After you have reviewed and accepted your settings, the installer will download Composer and set everything up. If your
environment has been changed, it is important to close your current terminal and open a new one so that the changes get
loaded. The installer will remind you if this is the case.

Использование подключенных пакетов

Для использования установленных Composer’ом библиотек, необходимо добавить автозагрузку. В современных приложениях используется паттерн front controller, он позволяет иметь единую точку доступа в приложение. То есть все запросы к приложению заходят в него, а он определяет каким контроллером должен формироваться респонс. Если в вашем приложении такого нет, то страшного нет ничего, вам просто придётся подключать файл автозагрузки во всех местах, где вы собираетесь использовать установленные библиотеки.

Например, у меня приложение состоит из одного файла — index.php, автозагрузку мне необходимо написать в нём.

index.php с подключенной автозагрузкой выглядит следующим образом

PHP

<?php require_once ‘vendor/autoload.php’;

1
2
3

<?php
 

require_once’vendor/autoload.php’;

Всё, везде ниже можно теперь использовать подключенные библиотеки.

Давайте воспользуемся установленной библиотекой и напишем приложение, которое сгенерирует файл для Excel с записю Hello, world! в первой ячейке.

Вдаваться в подробни как работать с PHPExcel не будем, т.к. это уже было описано в статье использование PHPExcel библиотеки, поэтому сразу приведу код файла index.php

PHP

<?php require_once ‘vendor/autoload.php’;

$document = new \PHPExcel();

$sheet = $document->setActiveSheetIndex(0);
$sheet->setCellValueByColumnAndRow(0, 1, ‘Hello, world!’);

$objWriter = \PHPExcel_IOFactory::createWriter($document, ‘Excel5’);
$objWriter->save(«Hello.xls»);

1
2
3
4
5
6
7
8
9
10
11

<?php
 

require_once’vendor/autoload.php’;

$document=new\PHPExcel();

$sheet=$document->setActiveSheetIndex();

$sheet->setCellValueByColumnAndRow(,1,’Hello, world!’);

$objWriter=\PHPExcel_IOFactory::createWriter($document,’Excel5′);

$objWriter->save(«Hello.xls»);

Как видите, в коде мы используем классы, предоставленные библиотекой PHPExcel.

Запустим скрипт командой

php index.php

Он отработает и создаст файл Hello.xls, открыв который, можно обнаружить следующее

Hello word в xls

Composer значительно упрощает разработку, вам нет необходимости скачивать откуда-то готовые библиотеки и скрипты, а затем подключать их с помощью include. Composer всё делает за вас сам. При этом, при переносе кода вашего проекта, вам не нужно тянуть готовые библиотеки, вы можете перенести только свой код, а затем просто установить эти библиотеки с помощью Composer.

Надеюсь статья оказалась вам полезной и вы узнали о Composer и теперь облегчите себе жизнь, применяя его.

Использование репозитория в Composer

После того как репозиторий заработал, последним шагом нужно будет сообщить Composer’у, что мы хотим использовать его. Это может быть сделано путем добавления следующих строк в файл вашего проекта.

{
    "repositories" : [
        {"type" : "composer", "url" : "http://localhost:8001/"}
    ],
    ...
}

После этого, при запуске будет использоваться наше хранилище:

$ composer install
Loading composer repositories with package information
Installing dependencies (including require-dev)
  - Installing symfony/http-foundation (v2.6.6)
    Downloading: 100%
 
Writing lock file
Generating autoload files

Мы видим в файле composer.lock, что URL-адрес на загрузку больше не указывает на GitHub, а на наш собственный репозиторий:

{
    ...
    "packages": [
        {
            "name": "symfony/http-foundation",
            "version": "v2.6.6",
            "target-dir": "Symfony/Component/HttpFoundation",
            "source": {
                "type": "git",
                "url": "https://github.com/symfony/HttpFoundation.git",
                "reference": "8a6337233f08f7520de97f4ffd6f00e947d892f9"
            },
            "dist": {
                "type": "tar",
                "url": "http://localhost:8001/dist/symfony-http-foundation-8a6337233f08f7520de97f4ffd6f00e947d892f9-zip-3c2665.tar",
                "reference": "8a6337233f08f7520de97f4ffd6f00e947d892f9",
                "shasum": "04c8f9c294585c8fc982762f5181eab0083fdf3a"
            }
        }
    ...
}

Кроме того, мы можем увидеть запросы, которые делал Composer, чтобы получить сначала репозиторий (, включая ), а затем сам пакет:

 x.x.x.x:64826 : /packages.json
 x.x.x.x:64827 : /include/all$e0f2af5bfe26328fcc97241cbd95de682f4fbfaa.json
 x.x.x.x:64839 : /dist/symfony-http-foundation-8a6337233f08f7520de97f4ffd6f00e947d892f9-zip-3c2665.tar
Ссылка на основную публикацию