Как обновить композер linux

Upgrade guides for Composer 1.x to 2.0

For composer CLI users

• The new platform-check feature means that Composer checks the runtime PHP version and available extensions to ensure they match the project dependencies. If a mismatch is found, it exits with error details to make sure problems are not overlooked. To avoid issues when deploying to production it is recommended to run composer check-platform-reqs with the production PHP process as part of your build or deployment process.
• If a package exists in a higher priority repository, it will now be entirely ignored in lower priority repositories. See repository priorities for details.
• Invalid PSR-0 / PSR-4 class configurations will not autoload anymore in optimized-autoloader mode, as per the warnings introduced in 1.10
• On linux systems supporting the XDG Base Directory Specification, Composer will now prefer using XDG_CONFIG_DIR/composer over

/.composer if both are available (1.x used

/.composer first)

Package names now must comply to our naming guidelines or Composer will abort, as per the warnings introduced in 1.8.1

Deprecated —no-suggest flag as it is not needed anymore

PEAR support (repository, downloader, etc.) has been removed

update now lists changes to the lock file first (update step), and then the changes applied when installing the lock file to the vendor dir (install step)

HTTPS_PROXY_REQUEST_FULLURI if not specified will now default to false as this seems to work better in most environments

dev-trunk , dev-master and dev-default are no longer aliases for each other. The exact branch names are now preserved.

For integrators and plugin authors

• composer-plugin-api has been bumped to 2.0.0 — you can detect which version of Composer you run via PluginInterface::PLUGIN_API_VERSION
• PluginInterface added a deactivate (so plugin can stop whatever it is doing) and an uninstall (so the plugin can remove any files it created or do general cleanup) method.
• Plugins implementing EventSubscriberInterface will be deregistered from the EventDispatcher automatically when being deactivated, nothing to do there.
• Pool objects are now created via the RepositorySet class, you should use that in case you were using the Pool class directly.
• Custom installers extending from LibraryInstaller should be aware that in Composer 2 it MAY return PromiseInterface instances when calling parent::install/update/uninstall/installCode/removeCode. See composer/installers for an example of how to handle this best.
• The Composer\Installer class changed quite a bit internally, but the inputs are almost the same:
  • setAdditionalInstalledRepository is now setAdditionalFixedRepository
  • setUpdateWhitelist is now setUpdateAllowList
  • setWhitelistDependencies , setWhitelistTransitiveDependencies and setWhitelistAllDependencies are now all rolled into setUpdateAllowTransitiveDependencies which takes one of the Request::UPDATE_* constants
  • setSkipSuggest is gone
• vendor/composer/installed.json format changed:
  • packages are now wrapped into a «packages» top level key instead of the whole file being the package array
  • packages now contain an «installed-path» key which lists where they were installed
  • there is a top level «dev» key which stores whether dev requirements were installed or not
• Removed OperationInterface::getReason as the data was not accurate. There is no replacement available.
• PreFileDownloadEvent now receives an HttpDownloader instance instead of RemoteFilesystem , and that instance cannot be overridden by listeners anymore, you can however call setProcessedUrl or setCustomCacheKey.
• VersionSelector::findBestCandidate ‘s third argument (phpVersion) was removed in favor of passing in a complete PlatformRepository instance into the constructor
• InitCommand::determineRequirements ‘s fourth argument (phpVersion) should now receive a complete PlatformRepository instance or null if platform requirements are to be ignored
• IOInterface now extends PSR-3’s LoggerInterface , and has new writeRaw + writeErrorRaw methods
• RepositoryInterface changes:
  • A new loadPackages(array $packageNameMap, array $acceptableStabilities, array $stabilityFlags) function was added for use during pool building
  • search now has a third $type argument
  • A new getRepoName() function was added to describe the repository
  • A new getProviders() function was added to list packages providing a given package’s name
• Removed BaseRepository abstract class
• DownloaderInterface changes:
  • download now receives a third $prevPackage argument for updates
  • download should now only do network operations to prepare the package for installation but not actually install anything
  • prepare (do user prompts or any checks which need to happen to make sure that install/update/remove will most likely succeed), install (should do the non-network part that download used to do) and cleanup (cleaning up anything that may be left over) were added as new steps in the package install flow
  • All packages get first downloaded, then all together prepared, then all together installed/updated/uninstalled, then finally cleanup is called for all. Therefore for error recovery it is important to avoid failing during install/update/uninstall as much as possible, and risky things or user prompts should happen in the prepare step rather. In case of failure, cleanup() will be called so that changes can be undone as much as possible.
• If you used RemoteFilesystem you probably should use HttpDownloader instead now
• PRE_DEPENDENCIES_SOLVING and POST_DEPENDENCIES_SOLVING events have been removed, use the new PRE_OPERATIONS_EXEC , PRE_POOL_CREATE or other existing events instead or talk to us if you think you really need this. See below for more details.
• The bundled composer/semver is now the 3.x range, see release notes for 2.0 and 3.0 for the minor breaking changes there
• Run Composer with COMPOSER_DEBUG_EVENTS=1 set in the environment to show which events happen which might help you.

Detailed differences in event flow during dependency resolution, composer updates and installs

Composer v1

• Composer resolves dependencies (dispatching PRE/POST_DEPENDENCIES_SOLVING)
• It then iterates over all packages one by one (dispatching PRE_PACKAGE_INSTALL/UPDATE/UNINSTALL, then PRE_FILE_DOWNLOAD if needed, then POSTPACKAGE*)
• And finally writes the lock file at the end

Composer v2

The update and install process have been split up.

• Composer resolves dependencies (dispatching PRE_POOL_CREATE)
• It then writes the lock file and that’s the end of the update

Install then does:

• Dispatches PRE_OPERATIONS_EXEC with the full list of operations to be executed
• Downloads all the packages not in cache yet in parallel (dispatching PRE_FILE_DOWNLOAD for those not in cache yet)
• It then iterates over all packages and executes updates/installs/uninstalls in parallel (dispatching PRE_PACKAGE_INSTALL/UPDATE/UNINSTALL then POSTPACKAGE* but one package started last may finish installing before another is done for example).

For Composer repository implementors

Composer 2.0 adds support for a new Composer repository format.

It is possible to build a repository which is compatible with both Composer v1 and v2, you keep everything you had and simply add the new fields in packages.json .

Here are examples of the new values from packagist.org:

metadata-url

This new metadata-url should serve all packages which are in the repository.

• Whenever Composer looks for a package, it will replace %package% by the package name, and fetch that URL.
• If dev stability is allowed for the package, it will also load the URL again with $packageName

dev (e.g. /p2/foo/bar

dev.json to look for foo/bar ‘s dev versions).

Caching is done via the use of If-Modified-Since header, so make sure you return Last-Modified headers and that they are accurate.

Any requested package which does not exist MUST return a 404 status code, which will indicate to Composer that this package does not exist in your repository. Make sure the 404 response is fast to avoid blocking Composer. Avoid redirects to alternative 404 pages.

The foo/bar.json and foo/bar

dev.json files containing package versions MUST contain only versions for the foo/bar package, as <"packages":<"foo/bar":[ . versions here . ]>> .

The array of versions can also optionally be minified using Composer\Util\MetadataMinifier::minify() . If you do that, you should add a «minified»: «composer/2.0» key at the top level to indicate to Composer it must expand the version list back into the original data. See https://repo.packagist.org/p2/monolog/monolog.json for an example.

If your repository only has a small number of packages, and you want to avoid the 404-requests, you can also specify an «available-packages» key in packages.json which should be an array with all the package names that your repository contain. Alternatively you can specify an «available-package-patterns» key which is an array of package name patterns (with * matching any string, e.g. vendor/* would make composer look up every matching package name in this repository).

providers-api

The providers-api is optional, but if you implement it it should return packages which provide a given package name, but not the package which has that name. For example https://packagist.org/providers/monolog/monolog.json lists some package which have a «provide» rule for monolog/monolog, but it does not list monolog/monolog itself.

This is also optional, it should accept an optional ?filter=xx query param, which can contain * as wildcards matching any substring.

It should return the names of package which names match the filter (or all names if no filter is present). Replace/provide rules should not be considered here.

Composer and all content on this site are released under the MIT license.

Источник

Как пользоваться Composer

Язык программирования PHP очень стремительно развивается. Ещё несколько лет назад огромным количеством библиотек на все случаи жизни мог похвастаться только Python. Однако сейчас уже разработано огромное количество библиотек для PHP, и все они доступны для установки буквально в несколько команд.

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

Синтаксис и опции Composer

Первое, что необходимо сказать, Composer — это консольная утилита, у неё нет графического интерфейса, однако это не делает её хуже. Вот её синтаксис:

$ composer опции команда

Опций у самой утилиты не так уж много. Давайте рассмотрим самые полезные:

• -h — вывести справку по утилите;
• -q — сокращённый вариант вывода;
• -V — показать версию утилиты;
• -n — не задавать интерактивных вопросов;
• -v, -vv,-vvv — настройка подробности вывода;
• -d — использовать указанную рабочую директорию.

Более интересны команды, которые вы будете постоянно использовать:

• archive — архивирует текущий проект в качестве библиотеки для отправки в Сеть;
• check-platform-reqs — проверяет, соблюдены ли системные требования;
• create-project — создаёт проект на основе пакета в указанную директорию;
• depends — выводит зависимости пакета;
• dump-autoload — обновляет систему автозагрузки классов;
• exec — позволяет выполнять скрипты из установленных пакетов;
• init — создаёт пустой проект в текущей папке;
• list — выводит список доступных команд;
• outdated — выводит список пакетов, для которых есть обновления;
• prohibits — выводит названия пакетов, которые мешают установить указанный пакет;
• search — поиск пакетов в репозиториях;
• self-update — обновление Composer до последней версии, работает только при локальной установке;
• show — информация о пакете;
• update — обновляет все пакеты до самой актуальной версии.

Большинство из этих опций мы разберём чуть ниже, в примерах использования composer. А пока давайте посмотрим, как его установить.

Установка Composer

Прежде, чем что-либо делать, утилиту надо установить. Инсталлировать Composer можно глобально для всей операционной системы или только в опредёленную папку. Для глобальной установки в Ubuntu используйте команду:

sudo apt install composer

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

mkdir new_project && cd new_project

Затем скачайте последнюю версию утилиты такой командой:

php -r «copy(‘https://getcomposer.org/installer’, ‘composer-setup.php’);»

Установка Composer выполняется командой:

После установки в директории появится файл Сomposer.phar, который и следует запускать для работы с утилитой. В Windows вы можете установить Composer только таким способом. Дальше в статье я буду считать, что утилита установлена глобально в системе, но дела это не меняет, просто будет отличаться имя исполняемого файла:

$ php ./composer.phar команды

Важно отметить, что для работы последней версии утилиты необходимо, чтобы в вашей системе была установлена версия PHP не ниже 7.0. Иначе утилита установится, но во время запуска будут выдаваться ошибки. Если вы используете панель управления, в которой есть несколько версий PHP, то нужно передать путь к утилите бинарному файлу PHP нужной версии, например:

$ /opt/php7.0/bin/php7.0 ./composer.phar команды

Путь к бинарному файлу будет отличаться в зависимости от способа установки PHP, панели и версии интерпретатора.

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

php composer.phar -V

Чтобы удалить Composer, достаточно удалить его файлы из папки, куда он был установлен. Чтобы обновить Composer до последней версии, выполните:

php composer.phar self-update

Теперь пора переходить к примерам работы с Composer.

Как пользоваться Composer

1. Проект на основе пакета

Чаще всего вы будете разворачивать проекты Composer на основе уже существующих пакетов. В этом случае утилита берёт пакет из репозитория и просто распаковывает его в текущую папку, а все зависимости уже помещаются в папку vendor. Для этого используется команда create-project. Давайте создадим проект на основе пакета slim/slim4-skeleton:

composer create-project slim/slim-skeleton ./

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

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

Для установки пакетов в Composer используется команда require. Утилита установит нужный пакет в подпапку vendor, добавит его в автозагрузку и в файл composer.json. Например, установим пакет illuminate/eloquent:

composer require illuminate/eloquent

Кроме того, composer позволяет устанавливать пакеты, которые будут доступны только для разработчика. Для этого используйте опцию —dev:

composer require —dev phpunit/phpunit

Бывают случаи, когда пакет не хочет устанавливаться из-за несовместимости с платформой. В первую очередь надо убедится, что все необходимые ему расширения PHP в системе установлены. Если же ваша консольная версия PHP использует другие расширения, а сам пакет будет использоваться только с веб-сервером, можно отключить проверку системных требований пакета с помощью опции —ignore-platform-reqs:

composer require —ignore-platform-reqs illuminate/eloquent

Ещё одна ошибка, которую вы можете получить — это не соответствие минимальной стабильности пакета. Например:

имя_пакета requires ещё_один_пакет -> satisfiable by точное_имя_этого_пакета but these conflict with your requirements or minimum-stability

Все пакеты Composer могут иметь два уровня стабильности:

• stable — стабильный;
• dev — находится в разработке.

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

Или, если в файле уже есть строчка minimum-stability, необходимо заменить её значения со stable на dev. После этого вы сможете установить пакет composer, который вам необходим. Напоминаю, что все команды Сomposer аналогичны, даже если Сomposer на хостинге, а не на локальной машине или VPS-сервере, надо только указать верный путь к его исполняемому файлу.

3. Удаление пакетов

Чтобы удалить пакет, который вам больше не нужен, используйте опцию remove:

composer remove illuminate/eloquent

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

composer remove —dev illuminate/eloquent

4. Обновление пакетов

Чтобы в ваших пакетах не было уязвимостей и старых проблем, необходимо регулярно их обновлять. Для этого используется команда update. Обратите внимание, что обновляются пакеты только в текущей директории, а не по всей системе, поэтому обновлять придётся каждый проект по отдельности:

И для пакетов разработчиков:

composer update —dev

5. Сброс автозагрузки

Бывает, что вы создали новый класс или установили пакет, но классы из него всё ещё не видны, и при попытке обратится к ним вы получаете ошибку. В таком случае следует обновить кэш автозагрузки Composer:

После этой команды всё должно заработать. Если нет — пакет несовместимый или если это ваш класс, то он не соблюдает стандарт PSR-4.

6. Создание пакета

Теперь вы знаете, как использовать Composer, давайте немного поговорим о создании своих пакетов. Чтобы создать пустой проект в текущей папке, достаточно выполнить команду:

Утилита задаст несколько вопросов:

• Package name — имя нового пакета в формате: автор/имя;
• Description — описание;
• Author — автор пакета;
• Minimum Stability — стабильность пакета, можно выбрать dev или stable;
• Package Type — тип проекта, например: library, project, metapackage, composer-plugin;
• License — лицензия;
• Depencies — здесь вы можете интерактивно найти пакеты, от которых будет зависеть ваш проект.

На последнем шаге утилита предложит вам проверить, всё ли верно указано в конфигурационном файле:

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

После того, как проект был создан, вы можете создать в папке проекта git-репозиторий и загрузить его на GitHub или другой сервис. Сразу же после этого ваш пакет можно будет установить с помощью Composer в любой другой проект, просто добавив его репозиторий.

7. Установка пакетов из сторонних репозиториев

Сначала нужно добавить ссылку на репозиторий в composer.json. Я предполагаю, что ваш репозиторий публичный, значит никаких ключей авторизации не понадобится:

«repositories»: [
<
«type»: «vcs»,
«url»: «ссылка на git репозиторий»
>
]

Секцию repositories надо добавлять на тот же уровень, что и license. и другие основные секции. Затем можно просто установить свой пакет:

composer require sergiy/selenium-chrome-library

После этого папка пакета появится в подпапке vendor, а его классы будут добавлены в автозагрузку.

Выводы

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

Источник