composer/composer

Dependency Manager for PHP

Dependency Management for PHP

Composer helps you declare, manage, and install dependencies of PHP projects.

See https://getcomposer.org/ for more information and documentation.

Installation / Usage

Download and install Composer by following the official instructions.

For usage, see the documentation.

Packages

Find public packages on Packagist.org.

For private package hosting take a look at Private Packagist.

Community

Follow @packagist or @seldaek on Twitter for announcements, or check the #composerphp hashtag.

For support, Stack Overflow offers a good collection of Composer related questions, or you can use the GitHub discussions.

Please note that this project is released with a Contributor Code of Conduct. By participating in this project and its community you agree to abide by those terms.

Requirements

Latest Composer

PHP 7.2.5 or above for the latest version.

Composer 2.2 LTS (Long Term Support)

PHP versions 5.3.2 - 8.1 are still supported via the LTS releases of Composer (2.2.x). If you run the installer or the self-update command the appropriate Composer version for your PHP should be automatically selected.

Binary dependencies

• 7z (or 7zz)
• unzip (if 7z is missing)
• gzip
• tar
• unrar
• xz
• Git (git)
• Mercurial (hg)
• Fossil (fossil)
• Perforce (p4)
• Subversion (svn)

It's important to note that the need for these binary dependencies may vary depending on individual use cases. However, for most users, only 2 dependencies are essential for Composer: 7z (or 7zz or unzip), and git.

Authors

• Nils Adermann | GitHub | Twitter | [email protected] | naderman.de
• Jordi Boggiano | GitHub | Twitter | [email protected] | seld.be

See also the list of contributors who participated in this project.

Security Reports

Please send any sensitive issue to [email protected]. Thanks!

License

Composer is licensed under the MIT License - see the LICENSE file for details.

Acknowledgments

• This project's Solver started out as a PHP port of openSUSE's Libzypp satsolver.

composer's Issues

Add InstallerInstaller

• Package with type "composer-installer" should be handled by it
• The new installer should be registered after being installed so it can be used to install packages immediately after in the same execution context
• Installed installers should be reconfigured automatically during composer bootstrap

Improve version selecting: dev vs stable

Right now, if you ask for >=1.0, and there is no stable version yet of the package, the dependencies are not resolved.

If a dependency can be solved with stable packages, we should prefer that, unless the user specifically asks for -dev/beta or whatever, but if it can not be solved with stable, yet there is an unstable package available, I think we should allow it to be selected, or at least report it clearly.

Policy Preference for replaced packages

There are packages A and B
Package B replaces A

User requests to install A.

If repo(B) has higher priority than repo(A), B should be installed.
If repo(A) has higher priority than repo(B), A should be installed.
if repo(A) has same priority as repo(B), A should be installed

If the user requests to install B instead, B should always be installed.

Do JSON schema validation

http://json-schema.org

We should validate the users' composer.json against doc/composer-schema.json.

We can use this PHP implementation: https://github.com/justinrainbow/json-schema

Add composer version in User-Agent header

When composer fetches info from a ComposerRepository, we should add the version in the UA header, it should be helpful for reporting on what versions are out there at some point.

CLI flag to not install recommended packages

Depends on #49. We should make the installing of recommended packages disable-able through a CLI flag.

Installation exits unexpectedly

Trying to install from the instructions on http://packagist.org/ and got the following result after running php composer.phar install:

mdp ~: php composer.phar install
??=??mdp ~: 

PHP version:

PHP 5.3.6 (cli) (built: Jul 31 2011 13:05:04)

Phar section of my php info:

Phar: PHP Archive support => enabled
Phar EXT version => 2.0.1
Phar API version => 1.1.1
SVN revision => $Revision: 307915 $
Phar-based phar archives => enabled
Tar-based phar archives => enabled
ZIP-based phar archives => enabled
gzip compression => enabled
bzip2 compression => enabled
OpenSSL support => enabled


Phar based on pear/PHP_Archive, original concept by Davey Shafik.
Phar fully realized by Gregory Beaver and Marcus Boerger.
Portions of tar implementation Copyright (c) 2003-2009 Tim Kientzle.
Directive => Local Value => Master Value
phar.cache_list => no value => no value
phar.readonly => On => On
phar.require_hash => On => On

Implement the support of phar archive

Silex for instance is distributed through a phar archive so this should be supported in composer too.

Add lint command to verify/validate a composer.json file

Add check for lock file integrity in `composer install`

If you call install, and have a lock file, it will install dependencies from the lock file. That's all good, but we should check if the packages described in the lock file actually match the requirements of the app composer.json.

If it doesn't match, we should proceed as usual, but output a warning to the user that probably he wants to run composer update to get some package versions that match with his current composer.json.

Logging instead of echo

Composer processes require some output from deep parts (like downloaders) and echo is used for such things. It's not cool. Logging can be used for such things, also cli can have options for different logging levels.

For example we can use Monolog with some ConsoleOutputHandler.

If you like this idea i will create PR with Monolog integration into Composer and PR in Symfony\Bridge or Monolog with ConsoleOutputHandler

Fix Path in Install Command

Hi, its me again and I came along another problem:
If you change the $vendorPath to something else you get an error during installation:

PHP Warning:  file_put_contents(vendor/.composer//autoload.php): failed to open stream: No such file or directory in /var/www/emc3/composer/src/Composer/Autoload/AutoloadGenerator.php on line 84
PHP Warning:  file_put_contents(vendor/.composer//autoload_namespaces.php): failed to open stream: No such file or directory in /var/www/emc3/composer/src/Composer/Autoload/AutoloadGenerator.php on line 85

which is caused by a fix path in Composer\Command\InstallCommand:157

$generator->dump('vendor/.composer/');

Dev Requirements

We might want to extend package.json with a dev-requires element, which specified additional dependencies only to be met when the package is installed in dev mode. This means there would be a bigger difference betweeen dev and non-dev mode, but one wouldn't have to depend on testing utilities in regular packages, and could still do so for development.

GitRepository needs to be fixed

Currently it acts only as a PathRepository (which is also something useful to have). It should be adjusted to support actual local and remote git repos, using cloning.

It may be possible to re-use packagist code, especially for the branch and tag handling, see also #37 on packagist.

Another thing that needs to be addressed is locking. If we support specifying a git repo, we probably want to lock to a commit SHA-1, instead of an actual version. How does this fit into our current architecture? The json-schema needs to be extended to support: a) defining a branch or tag (basically a git ref), b) locking to a git commit id.

Do JSON format validation

The json-schema validation in #35 requires a valid json format. PHP's json_decode is not very helpful there, it would be nice if we could assist the user in fixing his formatting.

We might be able to build something on top of raiload:

• http://qntm.org/railroad
• http://qntm.org/files/railroad/demo.php

This could then be extracted into a separate lib and shared with the world.

Install executables into package local bin dir

We need to define a standard bin dir for projects into which executables provided by packages are installed. We need to find a standard way of defining executables in packages, we could for example require them to be located in a bin directory in the root of the package.

Give useful error message in solver

If the solver fails it currently doesn't give any useful feedback. It should.

Ping @naderman.

Add a README

Could maybe a very basic README or doc be added to this, so one can have at least some idea of what this project is aiming at? I'm not expecting to get full documentation on this, but at least an overview would be really appreciated.

Thanks.

Autoloader cannot work as is

I wanted to add some autoload configuration for my projects but it's not possible yet.

All packages are installed under a directory derived from the package name (symfony/console, symfony/symfony, ...). This provides a good isolation between different packages, but that's not enough. For "whole" libraries like Symfony or Monolog, it works fine because where the directory structure is the same as the namespace one. But for Symfony components or Symfony bundles, that's not the case.

For instance, Symfony\Components\Console is under vendor/symfony/console/. So, a PSR-0 autoloader won't be able to handle this case. What about adding a base_path configuration in the composer.json file? That way, we can instruct Composer to install the files under vendor/symfony/console/Symfony/Component/Console.

Note that this will solve the bundle issue as we won't have to manage it differently than any other library. One downside is that the same namespace can be found under more than one directory, which means that you need an autoloader that is able to handle this case.

Another possibility could consist of the creation of symlinks but I can see many problems: Windows support, possible confusion if you install the symfony/symfony package and the symfony/console one for instance.

Smart branch and -dev handling

Some considerations from an IRC discussion.

• There needs to be a 'dev' flag for handling 'dev' versions differently
• 1.0.0 composer.json in master, but no tag => ad-hoc 1.0.0-dev version
• 1.0.0 composer.json in master, 1.0.0 tag => ignore master
• 1.0.0-dev composer.json in master, 1.0.0 tag => ignore master
• 1.0.0-dev is treated as 1.0.0, but needs to be explicitly required
• 1.0.0 tag containing a 1.0.0-dev composer.json => the -dev is stripped, 1.0.0 is assumed

Note: We don't want any implicit automatic bumping of versions, eg. from 1.0.0 to 1.1.0-dev.

Possible bug with replace: certain package not installed

The following composer.json:

{
    "require": {
        "silex/silex": ">=1.0.0-dev"
    }
}

Will install Silex with dependencies correctly. This includes a range of Symfony components, which are replaced by the "symfony/symfony" package.

However when you add "doctrine/orm", it will not install symfony.

{
    "require": {
        "silex/silex": ">=1.0.0-dev",
        "doctrine/orm": ">=2.1"
    }
}

Why not?

Package resolution is not case-insensitive

From packagist docs:

Note that package names are case-insensitive, but it's encouraged to use a dash (-) as separator instead of CamelCased names.

Since my package is called PhpFlo (similarly to NoFlo, the library it was ported to PHP from), I added it to packagist as PhpFlo/PhpFlo. However, this makes it not installable:

{
    "require": {
      "PhpFlo/PhpFlo": ">=0.0.1"
    }
}

$ php composer.phar install

[UnexpectedValueException]                                              
Package phpflo/phpflo could not be resolved to an installable package.  

Create init command to generate composer.json files interactively

Make vendor & $preferSource configurable

All of that is hardcoded in bin/composer right now, but imo it should really be args to the InstallCommand. Probably the default values should also be made configurable through the InstallCommand's constructor, so that people that want to integrate it in another environment can change the defaults easily.

This means that most of the bootstrapping done in bin/composer will have to be moved in the Command or somewhere else where it can receive the parameter from the Command.

Any package type should be allowed

Unknown package types should default to the library installer. If a package requires a custom installer it should specify that as a package requirement. The package will then only be installed after the custom installer is available for the type.

This will allow people to start using more specific package types before custom installers for the particular type are available.

Create validate command to check a composer.json for syntax or schema errors

Implement lock mechanism

@everzet can you provide some info here about how you envisioned this to work exactly according to the new architecture? I haven't had time to look into it too much.

Basically the idea would be to dump a file somewhere (composer.lock by default) that you can commit so that anyone using the project will install the exact same versions of the vendors, preventing some out-of-sync version issues from happening.

Support public/private download signing and verification

As some package maintaners may wish to sign the downloads (tar/phar, etc.) that they make available, there probably should be some method of easily distributing the public key or keys that are used to sign the packages, or at least working with locally stored package keys.

Storage of the public key(s) may or may not be something for composer.json itself, but it needs addressed regardless; seamless verification of packages with already-provided keys is going to be demanded for higher security platforms.

And obviously, downloading of public keys from a remote source should be out of the question. That would defeat the purpose of code signing and should not be made possible.

check environment before installing packages

I have a litte project in which I'm using Doctrine2, so added a composer.json file with the dependency and the URL for the package is https. But I haven't enabled the OpenSSL extension and php composer.phar install printed a very long stack trace when all I wanted to see was that the extension isn't enabled. I think it would be useful if there was a check if this extension (or any other needed) is avabilable.
Without SSL enabled, it throws 6 warnings and the actual error message is "could not be saved to vendor/doctrine/common/b8bd3b11382f1cc3594d7b72f52abe00, make sure the directory is writable and you have internet connectivity" which is not very helpful in this case.

It should be possible to define repos in composer.json

I don't remember the full syntax we had previously, but something among these lines was supported:

{
    "repositories": {
        "igor.io": {
            "type": "composer",
            "url": "http://not-packagist.org"
        }
    }
}

Users should be able to specify alternate package sources.

Local repository / package cache

All downloaded packages should be stored in a local repository, e.g. $HOME/.composer which is also automatically loaded. This will avoid duplicate download of the same package if you use composer in multiple projects.

Autoloader is looking in the wrong folder for Symfony\Console Classes

I cloned the repository, used the composer.phar to resolve the requirements and ran the composer command in the bin folder but I got this error:

PHP Fatal error:  Class 'Symfony\Component\Console\Application' not found in /home/pr/composer-testing/composer/src/Composer/Console/Application.php on line 28

The Application.php is loacted in /home/pr/composer-testing/composer/vendor/Symfony/symfony/console/Symfony/Component/Console/
After copying that file (and a few more) to /home/pr/composer-testing/composer/src/Composer/Console/the composer works.

Composer settings

Some settings like the name and location of the vendor dir should be configurable. We can do this in the project composer.json file but this would lead to confusion when it's packaged up. So maybe a separate config file is necessary.

RepositoryManager should support more than one repo of each type

Title says all. We need to be able to add many repositories of each type to the manager class, not just one as it is right now.

composer ignore file

When creating a composer package, .gitignore should be respected by default. Alternatively a .composerignore file following the same format should allow the definition of files not to be included in the package.

Move .composer into vendor dir

IMO composer shouldn't "pollute" the root dir beyond composer.json.

Also, deleting the vendor dir should clear composer's state, but right now if you don't delete .composer too it just tells you it's all good everything is installed, except it's not

Clarify recommends vs suggests

For optional dependencies there is recommends and suggests. What's the difference, if any?

These need to be documented and added to the JSON schema.

Add self-update command to update composer.phar

This should fail if it wasn't started from a phar file, otherwise it downloads the latest from http://getcomposer.org/composer.phar and replaces it.

make composer installable through pear

I would like to have the ability to install composer through pear.
for this to work we would need to create the proper package.xml and set up a pear repository, for which I would suggest pirum.
I can help out with this if needed.

Tyrael

Remove ClassLoader and generate a map

Composer comes with a simple implementation of an autoloader and I think this is a mistake. Composer should only be about packages, their dependencies, and their installation.

First, because it is a stripped down version of a "good" autoloader (there is no PEAR support for instance) and then, because I'm convinced that you will soon enough add all the features already available in the Symfony class loader (see #73).

Instead, I propose to just generate a map that can be used as a configuration for any autoloader you want to use (or generate):

// autoload.php
return array(
    'psr-0' => array(
        array(
            'mapping' => array('Monolog' => 'src/'),
            'path' => 'vendor/monolog/monolog',
        ),
    ),
);

or something like that.

Keep "pretty" representation of versions

Versions are converted to internal representation like 9999999-dev. May be a good idea to keep the original format too, in case we need to display it to the user.

Suggested packages should be listed

They are currently ignored when doing the installation AFAIK

Fatal error when installing monolog

Using the composer.json from the README:

{
    "name": "my-project",
    "version": "1.0.0",
    "require": {
      "monolog/monolog": "1.0.0"
    }
}

With today's composer.phar I get:

$ php composer.phar install
PHP Notice:  Undefined offset: 56 in phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Composer/DependencyResolver/Solver.php on line 2
PHP Stack trace:
PHP   1. {main}() /home/bergie/Projects/tmp/phpflo-test/composer.phar:0
PHP   2. require() /home/bergie/Projects/tmp/phpflo-test/composer.phar:15
PHP   3. Symfony\Component\Console\Application->run() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/bin/composer:48
PHP   4. Composer\Console\Application->doRun() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Symfony/Component/Console/Application.php:2
PHP   5. Symfony\Component\Console\Application->doRun() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Composer/Console/Application.php:2
PHP   6. Symfony\Component\Console\Command\Command->run() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Symfony/Component/Console/Application.php:2
PHP   7. Composer\Command\InstallCommand->execute() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Symfony/Component/Console/Command/Command.php:2
PHP   8. Composer\DependencyResolver\Solver->solve() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Composer/Command/InstallCommand.php:10
PHP   9. Composer\DependencyResolver\Solver->createTransaction() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Composer/DependencyResolver/Solver.php:2
PHP Fatal error:  Call to a member function getLiterals() on a non-object in phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Composer/DependencyResolver/Solver.php on line 2
PHP Stack trace:
PHP   1. {main}() /home/bergie/Projects/tmp/phpflo-test/composer.phar:0
PHP   2. require() /home/bergie/Projects/tmp/phpflo-test/composer.phar:15
PHP   3. Symfony\Component\Console\Application->run() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/bin/composer:48
PHP   4. Composer\Console\Application->doRun() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Symfony/Component/Console/Application.php:2
PHP   5. Symfony\Component\Console\Application->doRun() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Composer/Console/Application.php:2
PHP   6. Symfony\Component\Console\Command\Command->run() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Symfony/Component/Console/Application.php:2
PHP   7. Composer\Command\InstallCommand->execute() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Symfony/Component/Console/Command/Command.php:2
PHP   8. Composer\DependencyResolver\Solver->solve() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Composer/Command/InstallCommand.php:10
PHP   9. Composer\DependencyResolver\Solver->createTransaction() phar:///home/bergie/Projects/tmp/phpflo-test/composer.phar/src/Composer/DependencyResolver/Solver.php:2

Yesterday's composer.phar gives me:

[UnexpectedValueException]         
Invalid version string master-dev

Interestingly, yesterday the composer.phar worked with monolog.

composer.json in app shouldn't require name & version

ATM the composer.json from the end user is loaded through the ArrayLoader, which enforces that name & version be present. While I think it's cool that we would support that, effectively making your application a package of it's own, it shouldn't be required to specify those fields.

Complicated PackageInterface

Current interface for packages is really complicated and combines 2 areas: package definition and package storage.
For example we can separate it in 2 interfaces: one with information related to library (name, version, related packages, etc) and the second one with information about storage (distribution and source types, urls, etc.).

Also setters in interface look a little bit strange, i think this logic should be moved outside package interface.

What do you think?

Question: Adding PEAR packages to composer.json

I'm trying to see what composer has to offer (it sounds great).

How would I add a dependency for a pear packages on pear.php.net? E.g. I've tried this:

{
    "repositories": {
        "phppear": {
            "pear": "http://pear.php.net"
        }
    },
    "require": {
        "phppear/MDB2": ">=2.4.1"
    }
}

But I get the following error:

  [UnexpectedValueException]                                             
  Package phppear/mdb2 could not be resolved to an installable package. 

Obviously I'm not getting a key piece of the puzzle.

Any help gratefully received.

Thanks, Kelvin.

Create a publish command to create a package archive and send it to packagist

Similar to npm it should be possible to directly send a package to packagist using the commandline.

We might want to add support to publish to a local file based repository (not requiring a server) instead.

Recommended packages should be installed by default

AFAIK they are currently ignored.

Add --global option to install packages in $PATH bin dir and global code dir (e.g. /usr/lib/composer)

It should work like npm's option http://npmjs.org/doc/faq.html#How-do-I-install-something-everywhere

Globally installed packages will neither be in include_path nor in autoloaders of projects. If you want to install a dependency for a project, install it locally.

The only reason to install a package globally is to get some global commandline utility.

CLI flag to install suggested package

A CLI flag should allow installing suggested packages (similar to the PEAR --all-deps flag).

See also #51.