Nearly every README for a non-ancient PHP project begins with composer install. Some of them explain how to install composer itself, some of them don't and rely on developer's experience, web search engine of developer's choice, or implicitly on a globally installed composer.
Well, there's nothing wrong with that, really, but I think we can do better.
Here is a couple of assumptions:
- composer is meant to be up to date;
- composer is born to be installed locally (to be upgraded easily at will, for example).
So, if there was a script that checked if composer was there, installed it if it wasn't, upgraded if outdated, and finally proxied parameters as is to it as if we referred to a composer itself, all the issues outined above would have been solved...
- Copy
composerfile from this repository into a directory within your project where "binaries" (well, usually just CLI entry points) reside - Add it to version control
- Add
composer.pharin that directory into version control ignore file
Done, your colleagues should worry never again about installing composer and keeping it up to date, and neither should ops team care how it appears on a build server!
Just use the composer script instead of actual composer, and it will make sure you have an actual composer installed and up to date!
./composer install, ./composer update, ./composer dump-autoload, and other commands you used to should just work as if you had installed composer yourself.
All the configuration is done through environment variables in order to not interact with composer's CLI parameters. The following environment variables are supported:
COMPOSER_UPDATE_FREQ. Time between checks for updates (defaults to 7 days). This is a relative time specifier that is fed toDateTime::modify. It's chosen because it can be perfectly readable by someone who knows no PHP and doesn't want to (e.g. ops people), and it's recommended to keep it that way, e.g. "5 days", "2 weeks", "1 month".COMPOSER_DIR. Directory where composer.phar will be searched for and copied to. Defaults to the directory where the script is located (__DIR__); note: not the current working directory! Sometimes it's useful to keep real composer.phar a couple of levels higher up the directory where wrapper is placed, for example, on a CI server: it would help avoid downloading composer afresh for every build.
Well, you likely don't. It's intended to be as stupid as possible, and you probably have no reason to update it as long as it works. When it breaks, you just commit an updated version.
Sure, go ahead. It's CC0-licensed which basically means you don't owe the author anything, even a mention.
The wrapper is aimed to work in any environment that is supported by composer itself (hence, support all the PHP versions that composer supports). If this assumption doesn't work for you, feel free to open an issue or pull request.
Also, when opening a pull request, keep in mind the huge variety of PHP versions that composer supports.