My attempts include:
[ here i have python 3.9 so my constraints is 3.9]
I created a virtual environment and attempted to install Apache-Airflow by using pip install 'apache-airflow==2.5.1' / —constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.5.1/constraints-3.9.txt," but I received an error that I couldn't understand, so I looked on the stack community for advice and learned that I needed to add -t, which I did.
but then I started getting permission errors, then I went into community posts and how to fix permission errors, and it was suggested that I should run command prompt as administrator and then install unfortunately this thing isn't working for me
I've tried running cmd as administrator, going to my project's directory, activating virtualenv, and installing the library, but I still get the same problem. PermissionError: [WinError 5] Access is denied: 'D:\\'
Thanks in advance.
Try removing the slash (/) from the command before the --constraint and then running inside the cmd terminal; it will work.
pip install apache-airflow==2.5.1 --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.5.1/constraints-3.9.txt"
Note : Please be aware that the above recommendation is for Windows, but even if it is successfully installed you won't be able to run airflow because of the files used, such as pwd and others. Therefore, I will recommend that you use airflow in Windows using Ubuntu. You can follow this link to install Ubuntu in your system and set up airflow.
youtube-video-url
I'm running Vagrant version 2.2.19 with VirtualBox version 6.1 on Mac OS Monterey version 12.3.1.
When running vagrant up or vagrant up --provision, I'm receiving the following error:
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.
Upon checking the logs, in provisioner-utility-source-core.log I can see the following log:
[0;38;5;2m â–· Running the [0m[1m[0;38;5;5m'utility-source-core'[21m[0;38;5;2m provisioner...[0m[0m[0m
[0m[39m[2m* Updating the "core" utility on the "master" branch...[21m[0m
fatal: unsafe repository ('/srv/provision/utilities/core' is owned by someone else)
To add an exception for this directory, call:
git config --global --add safe.directory /srv/provision/utilities/core
[0;38;5;9m ! The [0m[1m[0;38;5;5m'utility-source-core'[21m[0;38;5;9m provisioner ran into problems, the full log is available at [0m[1m[0;38;5;5m'/var/log/provisioners/2022.04.18_18-32-31/provisioner-utility-source-core.log'[21m[0;38;5;9m. It completed in [0m[1m[0;38;5;5m0[21m[0;38;5;9m seconds.[0m[0m
In the above, can see a fatal error:
unsafe repository ('/srv/provision/utilities/core' is owned by someone else)
However, I cannot see any resources online to solve the above fatal error.
What I've tried:
Running vagrant halt then vagrant destroy and then vagrant up to create the box again, and then running vagrant up to see if it solves things (get the same error)
Added Git SSH (using this guide) in case it was a Git error
Uninstalled and then reinstalled VirtualBox
Cleared out IPs from /etc/hosts/hosts, and then ran vagrant up again, to see if there were any conflicts.
Have tried running git config --global --add safe.directory /srv/provision/utilities/core, then re-ran vagrant up --provision - but it does nothing.
Note: I have allowed oracle permissions via security and privacy and have rebooted my machine so it's in effect.
Is there any way to get VVV running again?
This is a known issue that was fixed in newer versions of VVV. Update to at least VVV 3.10.1 and re-provision.
If it is still happening despite updating to newer VVV, raise a GitHub issue.
I'm the VVV project lead, usually when we see these issues we fix them, this isn't something you should need to fix yourself. But if you use stackoverflow to report bugs we don't see it. Either raise a GitHub issue or ask in the VVV slack.
https://github.com/Varying-Vagrant-Vagrants/VVV/issues/new/choose
I tried to install Simple OAuth (https://www.drupal.org/project/simple_oauth) module in my drupal site running in a shared Godaddy hosting. My first mistake was not to read the installation guide instructing to install the module by using composer. Instead, I installed the module using the Extend=>install a module link within Drupal. Installing the simple_oauth and enabling the module crashed my site and there is no output from the site.
Then I realised there is something wrong with the installation and checked the error log file. The error logged was:
PHP Fatal error: Interface 'League\OAuth2\Server\Repositories\AccessTokenRepositoryInterface' not found in /home/-----------/public_html/drupal/modules/simple_oauth/src/Repositories/AccessTokenRepository.php on line 10
At that point I realised there is something wrong with the installation and checked the module instructions which states I should use composer to install the module. I tried to solve this problem by redoing the installation from the ssh by using composer and this command:
composer config repositories.drupal composer https://packages.drupal.org/8 && composer require drupal/simple_oauth:^3
Which did not work because GoDaddy shared hosting plan has only 512mb of rams and composer kills the command because of lack of memory.
I tried reading through and understand how Composer works. There were recommendations saying you should never use composer in a production site and you should run it on your computer and copy the composer.lock file which needs much less rams. I created a PHP server using XAMMP on my computer and copied the composer.json file to my computer and run composer update command in my computer. It downloaded the dependencies and stuff on my computer. And feeling I get the hang of it, I copied the composer.lock file in my drupal server, run composer update command and saw composer delete many stuff which I could not undo.
So my questions are: 1- Is there a way of rescuing this drupal site at this point? I deleted many composer dependencies as far as I can understand.
The new error log says: PHP Fatal error: Interface 'Symfony\Component\HttpKernel\HttpKernelInterface' not found in /home/--------/public_html/drupal/core/lib/Drupal/Core/DrupalKernelInterface.php on line 15
2- If not, which is fine as I was just beginning to setup the site. Is it possible for someone to explain the best way of handling this scenario? I mean installing a module using composer in a memory critical place. Or explain how composer works for layman. I read about all the dependency stuff but could not figure out how to use it for this scenario.
Thanks.
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 am trying to install Symfony 2.1.3 (latest). I am running composer and installs everything okay. The only error that I get is:
Script Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache
handling the post-install-cmd event terminated with an exception
[RuntimeException]
An error occurred when executing the "'cache:clear --no-warmup'" command.
It's being installed under www folder. I am running nginx and followed the composer approach. I read on internet that apache should be run manually not as a service, however I am using nginx instead. Does apache still have any bearing on it? I'm using debian squeeze.
Edit: As per AdrienBrault's suggestion the error was because the timezone was not set in the php.ini. Only with --verbose I could see the warning. Thanks guys.
Apache is not related - PHP is called via command line.
Most likely is the permission in the cache folder: did you check if the user that runs the composer update can actually write the cache folder?
Try to manually run rm -Rf app/cache/dev (for production environment replace dev with prod) and see if you get any permission error.
Also you will get this error if the default.timezone setting is not configured in php when running in CLI. To verify just run
php --info | grep timezone
and check that the setting date.timezone is correctly configured.
On the security side, setting 777 to the folder is not the optimal solution - if you have ACL enabled you could use that to correctly set up the permission for the cache and logs folder. Read more at the Symfony2 official installation page
I had this same issue for a while and after hours of face to brick wall pounding I realized... I have a .gitmodule in my project, and on initial checkout these submodules are NOT initialized and as such are not there for your composer to update, which results in the above error.
Make sure you run the following
git submodule update --init src/Acme/Sadness/Bundle
of course replace src/Acme/Sadness/Bundle with YOUR project namespace.
Hope this helps someone not go through the same pain I just did.
If you have vendor folder already I would remove it and install symfony 2.1.3 again via "composer.phar install". Problem might be coming from outdated version of composer
I had the same problem and I resolve in this way.
execute this on the console
and you should see something like this
$ locate php.ini
/etc/php5/apache2/php.ini
/etc/php5/cli/php.ini
/etc/php5/fpm/php.ini
the first line is probably your php.ini that appear when you do a phpinfo();
the problem is that when you execute composer update this no check the same php.ini
in my case the second line
all my sites work fine but always I had problems not now
after edit the second file and put the same time zone that you set in the first one
run
$ sudo service apache2 reload
and now
$ composer update
I hope that this work for you like work for me
regards
Emiliano