I'm trying to add a new composer dependency to my project, but it doesn't work. There's no error or anything - it just silently does nothing:
[vagrant#localhost project]$ composer require bshaffer/oauth2-server-bundle
Using version ^0.4.0 for bshaffer/oauth2-server-bundle
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
[vagrant#localhost project]$ composer update --verbose
Loading composer repositories with package information
Updating dependencies (including require-dev)
That's it. That's all the output. What is going on? Why isn't composer downloading and installing the package?
Additional info:
The machine has PHP 5.6 installed.
The project has Symfony 2.8 installed and a bunch of other libraries.
There is a composer.lock file, but no matter what I do, the bshaffer/oauth2-server-bundle doesn't get added to it. I'm afraid to completely delete and recreate the file.
Deleting vendor/ and other auto-generate files, and then running composer install results in all the libraries being reinstalled except bshaffer/oauth2-server-bundle.
It was a memory issue after all. The project is in a virtual machine with 2GB of RAM allocated. Since there is basically nothing else there, that's enough for smooth daily operation. Except composer, apparently. I increased the amount of available RAM to the VM, and here are the results:
At 2GB - terminates silently, no error messages or anything
At 4GB - terminates with an error message that there's not enough memory to fork.
At 8GB - Works as expected, woohoo!
Seriously, 8GB? Bloatware these days! When I grew up...
The composer is running in the background. To see the output simply use the verbose mode, so modify your commaand to
composer require bshaffer/oauth2-server-bundle -vvv
Also you can try deleting the lock file that is composer-lock.json before re running the command
Please delete the file composer-lock.json and then try running composer install.
Related
I am trying to use Composer to install dependancies inside a Docker container running PHP 5.6.40.
It runs, but quits and the vendor directory is always empty.
MacBook:my-app dev$ docker exec my-app_php56_1 php -d memory_limit=-1 composer.phar update -vvv --no-cache --no-plugins
Disabling cache usage
Running 1.9.0 (2019-08-02 20:55:32) with PHP 5.6.40 on Linux / 4.9.184-linuxkit
Do not run Composer as root/super user! See https://getcomposer.org/root for details
Reading ./composer.json
Loading config file ./composer.json
Checked CA file /etc/ssl/certs/ca-certificates.crt: valid
Executing command (/var/www/html): git branch --no-color --no-abbrev -v
Reading /root/.composer/composer.json
Loading config file /root/.composer/composer.json
Loading composer repositories with package information
Downloading https://repo.packagist.org/packages.json
Updating dependencies (including require-dev)
Downloading http://repo.packagist.org/p/provider-2013%24b962a943715f142bd3c36c0e87b67b28b16c014a98898622ec735220b7e1ee4f.json
Downloading http://repo.packagist.org/p/provider-2014%24ecc1513d9762efcfd48fdbaf4a08f829a59093064f40b7c351f93f3fbdd07973.json
Downloading http://repo.packagist.org/p/provider-2015%24258303eff7165b17439353fe44e501a3a6d600bd5b5482c5261a2ffa2234a947.json
Downloading http://repo.packagist.org/p/provider-2016%2496e2313b5ba90c2b798b03f9e306a27c15f11f763cd6478b834943fc128fc111.json
Downloading http://repo.packagist.org/p/provider-2017%24d2ad294ebaf381b7bf68cacbe514cf2bb33c3a919b97319bfa2e2ffaa66bc511.json
Downloading http://repo.packagist.org/p/provider-2018%2466893d07acdb18bb12d5e92e062b6e3058f5d284292b09cf585bf0ceb1b26aca.json
Downloading http://repo.packagist.org/p/provider-2018-10%24ff53e18093ae3e52a84c5567489c78bf1d82d0af80f413c3d6ad35d541a28434.json
Downloading http://repo.packagist.org/p/provider-2019-01%2431194ef7551ee4bffd7cc09dd6d01dc60848afc129544438ac7931e9d42dd54e.json
...
Downloading http://repo.packagist.org/p/phpspec/phpspec%248dc959bd0ae544f84e5bceee933d9a61d0a2074b208c3b7e7807cdc320e83eee.json
Downloading http://repo.packagist.org/p/phpspec/php-diff%249b8687b7c99f069823a9ac8d17900f9c8243368ceea9a5ac4e71ab424bb6f2d5.json
Downloading http://repo.packagist.org/p/squizlabs/php_codesniffer%24386b3726c6c3ce5edde180a7881f924be5dfd720c951dc93db8455ae871e9d61.json
MacBook:my-app dev$
It then just returns nothing and the vendor directory remains empty.
I am running composer without any plugins or cache.
Finally, the exact same composer.json file works fine in my other PHP 7.1.x container.
I also wondered if the final dependancies was causing an issue so tried removing it. Still no luck.
EDIT:
I've now gone back to my PHP 7.1 container and run the exact same scripts and it works fine. Composer's output is (so the 5.6 version just dies at the point that it does the "Resolving dependencies through SAT":
...
Downloading http://repo.packagist.org/p/webmozart/assert%24f23cf2d90bee4a1a09dc1d005896d60e715bdb9ecd4531874bfc3dd3ea5908c1.json
Downloading http://repo.packagist.org/p/phpspec/phpspec%248dc959bd0ae544f84e5bceee933d9a61d0a2074b208c3b7e7807cdc320e83eee.json
Downloading http://repo.packagist.org/p/phpspec/php-diff%249b8687b7c99f069823a9ac8d17900f9c8243368ceea9a5ac4e71ab424bb6f2d5.json
Downloading http://repo.packagist.org/p/squizlabs/php_codesniffer%24386b3726c6c3ce5edde180a7881f924be5dfd720c951dc93db8455ae871e9d61.json
Resolving dependencies through SAT
Looking at all rules.
Something\'s changed, looking at all rules again (pass #16)
Dependency resolution completed in 28.879 seconds
Analyzed 21713 packages to resolve dependencies
Analyzed 1376894 rules to resolve dependencies
Resolving dependencies through SAT
Looking at all rules.
Dependency resolution completed in 0.003 seconds
Package operations: 116 installs, 0 updates, 0 removals
Installs: kylekatarnls/update-helper:1.2.0, stripe/stripe-php:v2.3.0, abraham/twitteroauth:0.6.6, ralouphie/getallheaders:3.0.3, psr/http-message:1.0.1, guzzlehttp/psr7:1.6.1, guzzlehttp/promises:v1.3.1, guzzlehttp/guzzle:6.0.2, maknz/slack:1.7.0, maknz/slack-laravel:1.0.0, sabberworm/php-css-parser:8.1.0, phenx/php-svg-lib:v0.3.2, phenx/php-font-lib:0.5.1, dompdf/dompdf:v0.8.3, vlucas/phpdotenv:v1.1.1
...
etc for everything else
From the output of your run, it seems your composer setup is using http rather than https. Run this command before installing composer:
composer config -g repo.packagist composer https://packagist.org
This question is getting a little old now so I assume you already resolved it. I had the same problem recently.
The problem appears to stem from the change of PHP version. In my case I was going from 7.1 to 7.2, which you would imagine shouldn't cause too much of an issue.
My composer update -vvv --no-cache --no-plugins output would show
Resolving dependencies through SAT
Looking at all rules.
Something's changed, looking at all rules again (pass #[forever increasing])
After attempting to install symfony/thanks
In the end I had to remove symfony/thanks from my composer.json and run again. It then gave me some problems with a few other packages that I also removed. Once I had a successful run I was then able to start adding the offending packages back to my composer.json and eventually the issue was resolved.
I assume the underlying issue was a number of conflicts in the various levels of dependencies of my packages.
I guess if anyone finds they end up removing more and more packages, the solution would be to start from the minimum possible packages (the default Laravel composer.json in my case) and start adding new packages one-by-one.
Error:
Updating vlucas/phpdotenv (v2.4.0 => v2.5.1): The following exception
is caused by a lack of memory or swap, or not having swap configured
Check
https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors
for details
Currently the AWS Instance RAM: 2GB
Though we have fixed the issue by upgrading RAM from 2GB => 4GB but I have few doubts as increasing RAM this should not be the solution for a small site.
Could you please check the following points:
1) What is the recommended memory required by Laravel for updating the packages (composar.phar update)?
2) Does laravel use SWAP memory as well while composer update?
I had the same problem and never found the reason. You could run composer update --profile or even composer update --profile -vvv to have a detailed list of what's going on under the hood. The first one will show you how much memory is used.
It shouldn't be over 600Mb. But still you will run out of memory. As the laravel app goes into maintenance mode, it shouldn't add to it. You could run in a second shell the command top -ac and see what happens there.
The hosting company couldn't help me either as they blamed it on me lol.
But there is a way around. Upload the composer.lock only and on the production server run composer install --no-dev. It will give you a warning about outdated packages. Answer 'yes' and your prod server will be updated without a glitch. This command runs the laravel composer.json scripts commands too and updates the composer.json package versions..
Ideally, composer update is only run on your development environment, when you push your code in AWS server, the command you must use is composer install (which doesn't use too much memory).
If you want to know the difference between update or install, refer to this link: What are the differences between composer update and composer install?
I'm having an issue with composer.
I'm working with git in a local environment. I'm the only one developer.
When I need some more dependencies (or need to change some versions), I edit the composer.json and run composer install locally.
Everything's fine.
Then, when everything works locally, I commit my changes (including composer.json and composer.lock) and push to my production server.
A post-receive script updates the sources and runs a composer install on the remote server.
What is expected :
Composer should install the new dependencies according to the composer.lock file.
I should be happy.
What happens :
Composer is angry :
Warning: The lock file is not up to date with the latest changes in
composer.json. You may be getting outdated dependencies. Run update to
update them.
Composer removes all dependencies.
My production is broken.
I have a heart attack
I have to log in to my server via ssh and run a composer update to make things work fine, but I know that a composer update is not recommended on a production server.
Here's the output of the post-receive composer's section :
composer install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.
- Removing guzzle/guzzle (v3.9.3)
- Removing symfony/event-dispatcher (v2.7.1)
- Removing geoip/geoip (v1.15)
- Removing pimple/pimple (v3.0.0)
- Removing cocur/slugify (1.1.x-dev)
- Removing bentools/url (0.2)
- Removing bentools/simplexmlextended (1.2.0)
Generating autoload files
What am I doing wrong ?
Thanks,
Ben
This warning
Warning: The lock file is not up to date with the latest changes in composer.json, you may be getting outdated dependencies, run update to update them.
occurs when the md5sum of your composer.json differs from the one stored in the composer.lock:
{
"hash": "b15ed9405e8547867f74973ce8add172",
"packages": [ ... ]
}
Make sure your composer.json and composer.lock are identically with your local ones (compare their md5sums). I suspect that something in your deploy chain is not updating them correctly.
Make sure you added your dependencies locally with the require command:
composer require new/package ~2.5
or if composer.json was edited manually at least run
composer update new/package
after that for every additionally added package to ensure that it is added to your composer.lock properly.
Another approach:
run composer update --lock in production. This will update the hash in your lock file but won't upgrade your vendors.
Then run composer install to install the vendors from your comoser.lock.
When I need some more dependencies (or need to change some versions), I edit the composer.json and run composer install locally.
That's wrong. You can edit composer.json and then must run composer update, or you let Composer do the internal editing of the json file and just run composer require new/package (optionally with a version).
Either way, you should end up with a changed composer.json and composer.lock file, commit BOTH into your repository, and the expected outcome is that the lock file will contain all packages in the correct versions, which should be installed in production with a regular composer install run.
Note that your workflow is still very dangerous. If you push, and Github is down - how would you get the ZIPs to install?
A developer has sent me his project to work with, but when ever I try to update or install my vendors everything works great until the very end and it outputs the message bellow.
C:\xampp\htdocs\BigWaveMedia\davinkit>php artisan migrate
{
"error": {
"type": "Exception",
"message": "expected color value: failed at `.clearfix;` C:\\xampp\\htdocs\\BigWaveMedia\\davinkit\\app\\start\/..\/..\/public\/less\/style.less on line 102",
"file": "C:\\xampp\\htdocs\\davinkit\\vendor\\leafo\\lessphp\\lessc.inc.php",
"line": 3258
}
}
C:\xampp\htdocs\BigWaveMedia\davinkit>
Any ideas at all? Here is a full log http://pastebin.com/y9q4Rc5z
When you run composer update, composer generates a file called composer.lock which lists all your packages and the currently installed versions. This allows you to later run composer install, which will install the packages listed in that file, recreating the environment that you were last using.
It appears from your log that some of the versions of packages that are listed in your composer.lock file are no longer available. Thus, when you run composer install, it complains and fails. This is usually no big deal - just run composer update and it will attempt to build a set of packages that work together and write a new composer.lock file.
However, you're running into a different problem. It appears that, in your composer.json file, the original developer has added some pre- or post- update actions that are failing, specifically a php artisan migrate command. This can be avoided by running the following: composer update --no-scripts
This will run the composer update but will skip over the scripts added to the file. You should be able to successfully run the update this way.
However, this does not solve the problem long-term. There are two problems:
A migration is for database changes, not random stuff like compiling assets. Go through the migrations and remove that code from there.
Assets should not be compiled each time you run composer update. Remove that step from the composer.json file.
From what I've read, best practice seems to be compiling assets on an as-needed basis during development (ie. when you're making changes to your LESS files - ideally using a tool like gulp.js) and before deployment.
The following works for me:
composer update --no-scripts
this is command for composer update please try this...
composer self-update
write this command in your terminal :
composer update
You can use :
composer self-update --2
To update to 2.0.8 version (Latest stable version)
I am using latest symfony 2.1 and trying to install the doctrine fixture bundle.
I followed the instructions listed here.
Install composer and git as well. But now when I am trying to update the vendor libraries (php composer.phar update) I am getting the following error:
Loading composer repositories with package information
Updating dependencies
- Removing doctrine/dbal (2.3.0)
vendor\doctrine\dbal\lib\Doctrine - The directory is not empty.
[RuntimeException]
Could not completely delete vendor/doctrine/dbal,
aborting.
How can I solve this issue?
This occurs when a package directory in the vendor dir is locked for some reason by another application. This tends to happen on windows where many things can lock a directory/file.
If it's an intermittent issue, running composer update should fix it, but if it persists try to remove vendor\doctrine\dbal\lib\Doctrine by hand.
If it is really locked you won't be able to delete it either unless you close anything locking that dir. Using Unlocker can assist you if you have no idea what is holding a lock over the directory.