2012-08-24 09:53:02 +00:00
|
|
|
<!--
|
|
|
|
tagline: Solving problems
|
|
|
|
-->
|
2012-08-27 15:46:40 +00:00
|
|
|
# Troubleshooting
|
|
|
|
|
|
|
|
This is a list of common pitfalls on using Composer, and how to avoid them.
|
|
|
|
|
|
|
|
## General
|
|
|
|
|
2013-06-12 12:05:01 +00:00
|
|
|
1. Before asking anyone, run [`composer diagnose`](../03-cli.md#diagnose) to check
|
2013-04-03 22:47:03 +00:00
|
|
|
for common problems. If it all checks out, proceed to the next steps.
|
|
|
|
|
|
|
|
2. When facing any kind of problems using Composer, be sure to **work with the
|
2012-10-11 18:20:49 +00:00
|
|
|
latest version**. See [self-update](../03-cli.md#self-update) for details.
|
2012-08-27 15:46:40 +00:00
|
|
|
|
2013-04-03 22:47:03 +00:00
|
|
|
3. Make sure you have no problems with your setup by running the installer's
|
2013-02-18 16:56:13 +00:00
|
|
|
checks via `curl -sS https://getcomposer.org/installer | php -- --check`.
|
2012-10-30 11:54:53 +00:00
|
|
|
|
2013-04-03 22:47:03 +00:00
|
|
|
4. Ensure you're **installing vendors straight from your `composer.json`** via
|
2012-10-08 17:42:28 +00:00
|
|
|
`rm -rf vendor && composer update -v` when troubleshooting, excluding any
|
|
|
|
possible interferences with existing vendor installations or `composer.lock`
|
|
|
|
entries.
|
2012-08-27 15:46:40 +00:00
|
|
|
|
|
|
|
## Package not found
|
|
|
|
|
|
|
|
1. Double-check you **don't have typos** in your `composer.json` or repository
|
|
|
|
branches and tag names.
|
|
|
|
|
|
|
|
2. Be sure to **set the right
|
2012-10-11 18:20:49 +00:00
|
|
|
[minimum-stability](../04-schema.md#minimum-stability)**. To get started or be
|
2012-08-27 15:46:40 +00:00
|
|
|
sure this is no issue, set `minimum-stability` to "dev".
|
|
|
|
|
2012-11-08 14:08:02 +00:00
|
|
|
3. Packages **not coming from [Packagist](https://packagist.org/)** should
|
2012-08-27 15:46:40 +00:00
|
|
|
always be **defined in the root package** (the package depending on all
|
|
|
|
vendors).
|
|
|
|
|
|
|
|
4. Use the **same vendor and package name** throughout all branches and tags of
|
|
|
|
your repository, especially when maintaining a third party fork and using
|
|
|
|
`replace`.
|
|
|
|
|
2013-02-19 15:18:45 +00:00
|
|
|
## Package not found on travis-ci.org
|
|
|
|
|
|
|
|
1. Check the ["Package not found"](#package-not-found) item above.
|
|
|
|
|
|
|
|
2. If the package tested is a dependency of one of its dependencies (cyclic
|
|
|
|
dependency), the problem might be that composer is not able to detect the version
|
|
|
|
of the package properly. If it is a git clone it is generally alright and Composer
|
|
|
|
will detect the version of the current branch, but travis does shallow clones so
|
|
|
|
that process can fail when testing pull requests and feature branches in general.
|
|
|
|
The best solution is to define the version you are on via an environment variable
|
|
|
|
called COMPOSER_ROOT_VERSION. You set it to `dev-master` for example to define
|
|
|
|
the root package's version as `dev-master`.
|
2013-01-06 20:00:36 +00:00
|
|
|
Use: `before_script: COMPOSER_ROOT_VERSION=dev-master composer install` to export
|
2013-02-19 15:18:45 +00:00
|
|
|
the variable for the call to composer.
|
2013-01-06 20:00:36 +00:00
|
|
|
|
2013-04-27 15:51:05 +00:00
|
|
|
## Need to override a package version
|
2013-03-04 13:17:43 +00:00
|
|
|
|
2013-04-27 15:51:05 +00:00
|
|
|
Let say your project depends on package A which in turn depends on a specific
|
|
|
|
version of package B (say 0.1) and you need a different version of that
|
|
|
|
package - version 0.11.
|
2013-03-04 13:17:43 +00:00
|
|
|
|
2013-04-27 15:51:05 +00:00
|
|
|
You can fix this by aliasing version 0.11 to 0.1:
|
2013-03-04 13:17:43 +00:00
|
|
|
|
|
|
|
composer.json:
|
2013-04-27 15:51:05 +00:00
|
|
|
|
2013-03-04 13:17:43 +00:00
|
|
|
{
|
2013-07-31 08:30:18 +00:00
|
|
|
"require": {
|
2013-03-04 13:17:43 +00:00
|
|
|
"A": "0.2",
|
|
|
|
"B": "0.11 as 0.1"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-04-27 15:51:05 +00:00
|
|
|
See [aliases](aliases.md) for more information.
|
2013-03-04 13:17:43 +00:00
|
|
|
|
2012-08-27 15:46:40 +00:00
|
|
|
## Memory limit errors
|
2012-08-24 09:53:02 +00:00
|
|
|
|
|
|
|
If composer shows memory errors on some commands:
|
|
|
|
|
|
|
|
PHP Fatal error: Allowed memory size of XXXXXX bytes exhausted <...>
|
|
|
|
|
2012-10-16 18:49:01 +00:00
|
|
|
The PHP `memory_limit` should be increased.
|
2012-08-24 09:53:02 +00:00
|
|
|
|
2012-10-16 18:49:01 +00:00
|
|
|
> **Note:** Composer internally increases the `memory_limit` to `512M`.
|
|
|
|
> If you have memory issues when using composer, please consider [creating
|
|
|
|
> an issue ticket](https://github.com/composer/composer/issues) so we can look into it.
|
2012-08-24 13:06:03 +00:00
|
|
|
|
2012-10-16 18:49:01 +00:00
|
|
|
To get the current `memory_limit` value, run:
|
2012-08-24 09:53:02 +00:00
|
|
|
|
|
|
|
php -r "echo ini_get('memory_limit').PHP_EOL;"
|
|
|
|
|
2012-10-16 18:49:01 +00:00
|
|
|
Try increasing the limit in your `php.ini` file (ex. `/etc/php5/cli/php.ini` for
|
2012-08-27 15:46:40 +00:00
|
|
|
Debian-like systems):
|
2012-08-24 09:53:02 +00:00
|
|
|
|
2012-10-16 18:49:01 +00:00
|
|
|
; Use -1 for unlimited or define an explicit value like 512M
|
2012-08-24 09:53:02 +00:00
|
|
|
memory_limit = -1
|
|
|
|
|
2012-10-16 18:49:01 +00:00
|
|
|
Or, you can increase the limit with a command-line argument:
|
2012-08-24 09:53:02 +00:00
|
|
|
|
|
|
|
php -d memory_limit=-1 composer.phar <...>
|
|
|
|
|
2013-01-27 22:07:01 +00:00
|
|
|
## "The system cannot find the path specified" (Windows)
|
|
|
|
|
|
|
|
1. Open regedit.
|
|
|
|
2. Search for an ```AutoRun``` key inside ```HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor```
|
|
|
|
or ```HKEY_CURRENT_USER\Software\Microsoft\Command Processor```.
|
|
|
|
3. Check if it contains any path to non-existent file, if it's the case, just remove them.
|