I recently got this error when running bin/console doctrine:migrations:migrate:
The metadata storage is not up to date, please run the sync-metadata-storage command to fix this issue.
However, running the sync-metadata-storage command yields the same error.
What can I do?
As mentioned in this GitHub issue one possible fix is to specify the MySQL server version in the server URL:
DATABASE_URL=mysql://root:#127.0.0.1:3306/test?serverVersion=mariadb-10.4.11
Then, you should be able to run the bin/console sync-metadata-storage command.
Read more about this configuration option in the doctrine documentation:
[…] you can pass the serverVersion option with a vendor specific version string that matches the database server version you are using […]
If you are running a MariaDB database, you should prefix the serverVersion with mariadb- (ex: mariadb-10.2.12).
I had to downgrade the doctrine/doctrine-migrations-bundle to version "^2.1"
Not sure if that applies here, but I had issues with doctrine lately aswell.
I did a composer update and ever since then, my project wouldn't run anymore. My issue was based on a new version of the following bundle:
https://symfony.com/doc/master/bundles/DoctrineMigrationsBundle/index.html
They restructred the doctrine_migrations.yaml file and I still had the old one. I tried to change the contents to the new 3.0 version but that lead exactly to your error.
Since the bundle comes with the package: symfony/orm-pack you first have to unpack the to be able to manually change the version inside your composer.json: composer unpack symfony/orm-pack
After unpacking you will see the following line inside your composer.json: "doctrine/doctrine-migrations-bundle": "*", which I changed to "doctrine/doctrine-migrations-bundle": "^2.1". Then i ran composer update again. You may specify only the migrations bundle if thats all you want to update.
Hello so i could fixe my issue just by removing (?versionname=5.7) to the database_url and it worked just fine
I am developing a web application with Symfony 2. The code of my own bundle that forms the heart of my application and some configurations files for application-wide settings are controlled by Git (mostly the directories, src/MyCompany/MyBundle, app/Resources/config, etc.) The rest is under control of Composer (the framework, 3rd party bundles, etc.)
Up to now, I ran a ./composer self-update && ./composer.phar update once in a while, pushed or fetched source code from the origin of my repository and everything has been working well.
Today, I started a new fresh working directory and experienced some odd problems.
I performed
git clone <my git repo url> www
cd www
composer.phar install
The composer.json is part of my repository, hence it normally suffices to excute Composer in order to install the framework and all required bundles to get a fully working copy of my web application.
But today, composer.phar install stopped prematurely complainig about missing files. Luckily, I still had my old working directory, so I could copy over the missing files manually, and restart composer.phar. I had to repeat these steps several times until I ended with a fully working application.
The files that were missing are
app/console
AutoLoader.php
app_dev.php
AppCache.php
I thought that these files are part of the Symfony framework and expected them to be installed by Composer. Fot this reason they are not under control of my revision control system.
I found this related question. The answer is very generic und not particularly helpful. All it says is that for example app/console should be included into revision control, because it is not installed by Composer (any longer) and that there is a change in the directory structure due to the transition from Symfony 2 to 3. But I know for sure that app/console was installed by Composer in the past. Hence, something changed.
This leads me to the following questions
Is there any complete, up-to-date and official documentation
what should be included in the repository
what should be in .gitignore
what is managed by Composer?
Is there any documentation how to do the transistion from the old directory structure to the new one in preperation of Symfony 3?
I thought I read all README.md, all release information and everything in "Living on the Edge" of the Symfony site, but somehow I missed this.
The clean way to install Symfony2 from scratch with composer, is to use the following command:
composer create-project symfony/framework-standard-edition my_project_name
This will ensure that all basic structures are created. After that, you can still insert your customisations from the previous project.
Then you can add everything – except app/config/parameters.yml as well as the contents of vendor/, app/cache and app/logs – to your repository.
About transitioning to SF3, I guess there’ll be an upgrade path as soon as SF3 is stable enough to create such a document.
1.1. that depends how you want people to be able to fetch your bundle
1.2. I share with you my own .gitignore: beware I use git for my own use to have a security for my files, not to allow people to get my bundle:
# Cache and logs (Symfony2)
/app/cache/*
/app/logs/*
!app/cache/.gitkeep
!app/logs/.gitkeep
# Cache and logs (Symfony3)
/var/cache/*
/var/logs/*
!var/cache/.gitkeep
!var/logs/.gitkeep
# Parameters
/app/config/parameters.yml
/app/config/parameters.ini
# Managed by Composer
/app/bootstrap.php.cache
/var/bootstrap.php.cache
/bin/*
!bin/console
!bin/symfony_requirements
/vendor/
# Assets and user uploads
/web/bundles/
/web/uploads/
# PHPUnit
/app/phpunit.xml
/phpunit.xml
# Build data
/build/
# Composer PHAR
1.3. everything that is in composer.json
I have a Vagrant running Linux and I'm trying to install Symfony.
After the command composer create-project symfony/framework-standard-edition ./ "2.5.*" I have the error :
[RuntimeException]
Could not delete ./.git/objects/pack/tmp_idx_llwUKb:
If I try to composer update another project, I always have this kind of error Could not delete
Any ideas?
Edit: For a simple sudo composer update -vvv on another project:
- Installing sonata-project/admin-bundle (dev-master 8a022aa)
Failed to download sonata-project/admin-bundle from source: Could not delete /vagrant/crm_neo/vendor/sonata-project/admin-bundle/.git/objects/pack/tmp_idx_hchQhc:
Now trying to download from dist
- Installing sonata-project/admin-bundle (dev-master 8a022aa)
Failed: [RuntimeException] Could not delete /vagrant/crm_neo/vendor/sonata-project/admin-bundle/.git/objects/pack/tmp_idx_hchQhc:
[RuntimeException]
Could not delete /vagrant/crm_neo/vendor/sonata-project/admin-bundle/.git/o
bjects/pack/tmp_idx_hchQhc:
Exception trace:
() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:193
Composer\Util\Filesystem->unlink() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:151
Composer\Util\Filesystem->removeDirectoryPhp() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:129
Composer\Util\Filesystem->removeDirectory() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:35
Composer\Util\Filesystem->remove() at phar:///usr/local/bin/composer/src/Composer/Util/Filesystem.php:80
Composer\Util\Filesystem->emptyDirectory() at phar:///usr/local/bin/composer/src/Composer/Downloader/FileDownloader.php:108
Composer\Downloader\FileDownloader->doDownload() at phar:///usr/local/bin/composer/src/Composer/Downloader/FileDownloader.php:89
Composer\Downloader\FileDownloader->download() at phar:///usr/local/bin/composer/src/Composer/Downloader/ArchiveDownloader.php:35
Composer\Downloader\ArchiveDownloader->download() at phar:///usr/local/bin/composer/src/Composer/Downloader/DownloadManager.php:201
Composer\Downloader\DownloadManager->download() at phar:///usr/local/bin/composer/src/Composer/Installer/LibraryInstaller.php:156
Composer\Installer\LibraryInstaller->installCode() at phar:///usr/local/bin/composer/src/Composer/Installer/LibraryInstaller.php:87
Composer\Installer\LibraryInstaller->install() at phar:///usr/local/bin/composer/src/Composer/Installer/InstallationManager.php:152
Composer\Installer\InstallationManager->install() at phar:///usr/local/bin/composer/src/Composer/Installer/InstallationManager.php:139
Composer\Installer\InstallationManager->execute() at phar:///usr/local/bin/composer/src/Composer/Installer.php:548
Composer\Installer->doInstall() at phar:///usr/local/bin/composer/src/Composer/Installer.php:217
Composer\Installer->run() at phar:///usr/local/bin/composer/src/Composer/Command/UpdateCommand.php:128
Composer\Command\UpdateCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:252
Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:889
Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:193
Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:135
Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:124
Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:84
Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:43
require() at /usr/local/bin/composer:15
It happened once to me and it turns out that I was hitting composer's timeout.
You could take the following measures to gain some speed:
Increase composer process-timeout (default 300) (not really needed if the following settings will help you gain speed, but can't hurt)
Set dist as preferred install type.
Enable https protocol for github, which is faster.
~/.composer/config.json
{
"config": {
"process-timeout": 600,
"preferred-install": "dist",
"github-protocols": ["https"]
}
}
If you still have problems after that, you can also clear composer's cache:
rm -rf ~/.composer/cache
I was trying to update project dependencies (using composer update) during a Laravel Framework upgrade exercise in my local Homestead environment (having run vagrant ssh to login as the default "vagrant" user) and none of the previous answers in this thread made any difference to the...
Could not delete /home/vagrant/projects/projectname/vendor/kylekatarnls/update-helper/src/UpdateHelper
...error message I repeatedly encountered.
The only thing that worked for me was to include a composer option as follows:
composer update --no-plugins
Plugins are used to alter or extend the functionality of Composer. The above command disables all installed plugins. Unfortunately, I'm not clear as to why this command worked for me, as I certainly haven't written any plugins myself. All I can conclude is that there was an erroneous Composer plugin installed that was causing this issue.
TL;DR Switch to Docker. It is the industry standard.
I came across this issue and spent quite some time doing research. I've tried every possible option to fix it but none of them worked for me. For me, the bug occurred on GNU/Linux host with Vagrant and VirtualBox provider.
It turns out it's a VirtualBox bug related to the file system layer and race conditions when creating/deleting files. It occurs only for VirtualBox shared folders, not for regular ones. The sad part is that it seems like it's not going to be fixed any time soon.
Some guys reported that they were able to solve the problem using the following tricks:
Downgrading to VirtualBox version 6.0.4.
Using nfs or rsync instead of shared folders.
Patching composer to add some pauses after certain operations.
Disabling plugin usage with --no-plugins option.
But all of this seemed dirty to me. I personally was able to use a workaround suggested on GitHub which is to configure composer to install packages from sources. That's a simple and kind of clean trick which should not have significant negative side effects on your workflow. Try putting the following config into your ~/.config/composer/config.json. Or instead you can edit your composer.json accordingly depending on your needs. Keep in mind that composer.json will override your global config.
{
"config": {
"preferred-install": "source"
}
}
Just got the same issue.
I see the problem in accessing to some local files. In my case target directory was under "root" and I'm not the root user.
Solution
Change permissions/owner of your files/directory.
Redefine owner:
sudo chown myuser:myuser -R /path/to
Maybe there is some lack of permissions for group which you are in.
So, try to run:
sudo chmod g+rwX -R /path/to
Or maybe you may run your command with "sudo" if it works for you (not recommended). :)
P.S. Never use 777. It's not secure.
UPD1
Another thing, you may found out useful to solve the root of the cause, to wrap up your composer binary to run it always behalf a certain user.
$ cat /usr/local/bin/composer
#!/bin/bash
# run composer behalf www-data user
set -o pipefail
set -o errexit
set -o nounset
#set -o xtrace
[[ "${DEBUG:-}" = "true" ]] && set -o xtrace || true
composer_debug=$([[ 'true' != "${COMPOSER_DEBUG:-}" ]] || echo '-vvv' )
sudo -u www-data -- /usr/bin/composer ${composer_debug:-} $#
I had this problem when provisioning the machine, which was bootstrapped to run composer install. I simply exited the VM and ran composer install on the code on my host machine and it worked.
So, if you're facing this problem while running Composer inside the VM, just try running Composer from outside the VM.
Update: As pointed in the comments below, this can pose some problems with different versions of packages being installed owing to the difference in system configurations between the local and Vagrant environments, so exercise appropriate caution while trying this.
We're running into issues also. There are several people who seem to have this issue, a fix has not been provided. For more information you can look into github issues of vagrant-winnfsd.
for my case, I only used the NFS folders type instead of the shared folders and it works:
folders:
- map: ~/code/cs-cart-trial
to: /home/code/cs-cart-trial
type: "nfs"
Just run
sudo chmod -R 777 /folder/path
This will give you write access to the folder you are running composer in.
I know this is an old post but this works so I have to share it.
In my case I was trying composer update but I got
[RuntimeException]
Could not delete .../vendor/bin/php-parse:
Despite I'm using Laravel framework, this question was the first link in Google, so I decided to post an answer.
My solution was to grant ownership for vendor: sudo chown -R $USER:www-data vendor/ and
sudo chown -R $USER:www-data composer.json
Update: my host OS was Ubuntu 16.04.
Having the same issue for Cakephp 4.2.1
Error:
Could not delete /var/www/vendor/cakephp/plugin-installer/src:
Solution:
Based of https://stackoverflow.com/a/63139337/1110760
After trying out several options mentioned above, for me this was the easiest way to solve it.
composer install --prefer-source
The argument --no-plugins worked as well, sort of. It skipped some packages but my localhost seemed to work just fine. This is faster, but it's missing some.
On AWS I got this error while deploying Yii framework project there was this
/var/app/current/vendor/
folder i deleted everything inside it came back to my document root and ran composer update it fetched all the repos again.
In my case , by removing the plugin and re-create the box solve the issue.
For me it caused by composer's timeout. I checked my internet speed and found it dropped to 0.7M which is nearly unusable. After I reconnected the wifi and have my internet connection speed back to normal, the errors are gone.
This has something do to with the synchronization of the folders between host and guest OSes, the folder might be simply temporarily locked from your host machine.
The solution is simply to delete the offending .git folder from your host OS or reboot the machine and launch composer install again.
Ideally each OS has its own dependencies and different binaries, therefore you should isolate your /vendor folder out from the rsync/vagrant folder share, likewise you would do the same with /node_modules on a Nodejs project.
Another thing to check for, Composer needs to run in the context of a directory it has permissions to.
In my case I was trying to issue a create-project command from /var/www, aimed against /var/www/html. /var/www is owned by root, /var/www/html is owned by the same user I executed Composer as (www-data). I got the following error; Could not delete /var/www/html/:
Issued the same Composer command from within /var/www/html itself and it worked perfectly.
To me it helped to install a (new) version via command line from download homepage https://getcomposer.org/download/. I can exclude some file permissions as I was root with chmod +R 0777, though I had virtualbox mounted drive. Anyway since new version worked, would mean it was version, or running a new version via php phar, and the original bin belonged to root
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === '48e3236262b34d30969dca3c37281b3b4bbe3221bda826ac6a9a62d6444cdb0dcd0615698a5cbe587c3f0fe57a54d8f5') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
I have solved the problem by creating a mount :
In /home/vagrant create a folder named vendor
then apply command : mount --bind /home/vagrant/vendor /path/to/source/vendor
It's a bit unrelated with the question, but in my case with Docker. It was failing because Webpack was watching and it didn't allow other files to be deleted.
It worked when I turned off Webpack.
I had same problems trying composer install
- Installing aws/aws-sdk-php (3.218.3): Extracting archive
Install of aws/aws-sdk-php failed
In Filesystem.php line 330:
Could not delete /home/vagrant/code/my-project/vendor/composer/cefa44c2/aws-aws-sdk-php-a1bd217/src:
What I did I comment it out
type: "nfs"
from my homestead.yaml
and make a fresh vagrant provision
I'm using Oracle Virtual box 6.1 on Windows 10.
Turn of Dropbox or other file sync
Best hack i found was to replace the unlink commands with the one below. I am running ubuntu.
sudo nano +219 /usr/share/php/Composer/Util/Filesystem.php
exec("sudo rm -rf $path");
return true;
For Windows users
Wow, I can't believe how long it took me to realize this, and sadly it has happened multiple times, and I'm finally writing this note so that I and others can quickly recover next time.
Just use Windows Explorer to go delete the /vendor/whatever_project_name folder instead of trying to delete it from the Vagrant command line.
Then run composer update to reinstall the dependencies.
I have a little problem to setup Symfony 2 on Cloudcontrol,
I followed the instructions and installed a Symfony 2 framework, changed the document root and so on.
Now when I try to push the changes to server server, it loads the dependencies from the composer.json and then it failed with a message :
[RuntimeException]
Could not scan for classes inside "/srv/tmp/builddir/code/vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Resources/stubs" which does not appear to be a file nor a folder
This file is a vendor package, loaded from composer.
I have the same effect with a default composer.json file from a sample project (SF2)
Localy it works very well!
Can some one give me a hint ?
Got same error after setting "minimum-stability":"dev" and running composer update.
for unknown reason symfony/symfony (dev-master ...) kept failing to download from source thus was being loaded from cache.
what worked for me was a mix of previous answers:
$ rm -rf vendor/symfony
$ composer clearcache
$ composer install
Sometimes I had to clean composer cache to remove strange errors, usually it's in
/home/user/.composer/cache
You can also try to update composer with
php composer.phar self-update
I hope it runs for you.
I had the exact same error in my development directory.
What fixed it was :
$ rm -rf vendor/symfony
$ php composer.phar install
It reinstalled symfony/symfony, symfony/icu, symfony/assetic-bundle, symfony/monolog-bundle and symfony/swiftmailer-bundle and now everything works !
So I am a new to doctrine, but I am not able to install a bundle at all. I am following the guide, but the "error" which I am getting is very unusual.
Anyhow, I add this lines into deps file:
[FOSRestBundle]
git=http://github.com/FriendsOfSymfony/FOSRestBundle.git
target=bundles/FOS/RestBundle
Then I do:
./bin/vendors install
And I get:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626+lfs/sqlite.so' - /usr/lib/php5/20090626+lfs/sqlite.so: cannot open shared object file: No such file or directory in Unknown on line 0
Your project seems to be based on a Standard Edition that includes vendors.
Try to run ./bin/vendors install --reinstall
So on this standard way I am not able to install it at all. Can somebody explain me what is the problem, because to me it looks like, the symfony vendors script doesnt recognize changes in deps file at all.
This happens when you've downloaded the Symfony2 Standard Edition from the website. The vendor install script checks to see if the vendor directories are git repositories, and if not, will throw this error. You can fix the situation in one of two ways:
you can either run the command that it suggests: php bin/vendors install --reinstall
or, you can remove the vendors directory, then run php bin/vendors install, which amounts to about the same thing
No need to install that. Just follow the steps in the url : http://mmoreramerino.github.com/GearmanBundle/installation.html