I have several private repos stored on Github and made available on Packagist.
Due to some stability issue, these packages were later moved into private Bitbucket and added to our private Satis. (removed from Packagist)
The issue is that when we try to run 'composer update' on our machine it still tries to pull from Github paths.
I have tried everything including:
Deleted everything in the current folder to pull again
Clear cache with the new clear-cache command and also with rm -rf
Nothing worked.
Is this considered a bug? What do I have to do to make sure composer never tries to use the old repo path?
(I posted this on Composer issues as well but haven't got any solution there yet)
Related
I'm using yarn berry and heroku and consistently getting the error:
➤ YN0028: │ The lockfile would have been modified by this install, which is explicitly forbidden.
Which suggests that my lockfile does not contain all my listed dependencies. In the yarn docs it says this is easily solved by running yarn install and pushing new lockfile to git. However I've tried this, tried with fresh node_modules, etc with no luck.
Has anyone else experienced this issue using yarn berry + heroku?
My repo is a monorepo using workspaces.
I was able to workaround by setting the env-var YARN_ENABLE_IMMUTABLE_INSTALLS to false, as suggested here.
This is likely a bug in Yarn Berry. I've reported it here: https://github.com/yarnpkg/berry/issues/2948
UPD: I have created a fresh local clone of the repo from GitHub, ran yarn install in it, and it did produce changes in yarn.lock. Committing those changes resolved the CI issue, so disabling YARN_ENABLE_IMMUTABLE_INSTALLS is no longer necessary for me.
The original local repo showed a clean git status, so I still believe it is a bug.
UPD 2: My problem was that one of the Yarn worspaces was checked into git as a git submodule (I have probably created it with a nested .git/ folder and then deleted it). As a result, the workspace content, including a child package.json was not committed into the repo, it only existed in my local repo and not on the remote and CI.
After removing the git submodule and checking the workspace into the repo properly, the YN0028 error stopped happening.
If your ENV doesn't contain any CI variables:
Then it could be your yarn config:
Run yarn config get enableImmutableInstalls and see if it's enabled.
(you can also check why it is enabled by running yarn config --why and looking for enableImmutableInstalls).
If it is true, then run yarn config set -H enableImmutableInstalls false to set the setting's value globally (or without the -H argument to set it only in your current project)
I ran across the same issue. I resolve dit by deleting my cache and then reinstalling the dependencies.
The yarn.lock file was then modified by the time the reinstall had completed.
I believe this may have been because I checked in the cache folder initially, and then reverted it. Not sure if this then caused a discrepancy between my local environment and the checked-in repo.
I am curious if there is a way to have composer regenerate a new composer.lock without it actually going though the upgrade/install process? I just want to change the version in the lockfile for git without actually installing a local copy of the dependencies.
Is there a way to update the .lock file regarding mirrors, without updating versions?
I've started using toran, but it appears composer install is still using github for installing.
composer update updated some libraries, but many of the ones I'm using have not had a version change, and their entry in the .lock appears to be unchanged by the addition of a mirror.
To force Composer into reevaluating all of its install history for a project you should delete vendor/composer/installed.json, which is the internal cache file for what is installed and how. If you remove it and then composer install it will re-evaluate and reprocess the entire installation according to the settings in composer.json and the state in composer.lock.
I've got a client on a shared hosting environment (which I can't change) and I'm needing to install the Parse PHP SDK, but the host won't allow me to install the Composer package manager. Does anyone else know of a manual install method?
If you have wget/unzip available, just download latest release zip (bellow the release, this file).
Use unzip to unpack package and load it with PSR-4 autoloading (the composer's approach).
Composer isn't meant to be an installer, so you are not expected to run Composer on the production machine. What would happen if during your update process Github would be down? No new website version! And maybe also no old version.
Run Composer somewhere else, and then upload the result to the server, after you verified that everything went well.
There's always been a note in many Readmes of composer-based projects:
Never run composer update on production server
However, there are times that we want to run composer update on PROD servers to keep current (of course after a thorough test on local server). What's the best way to do that?
You should run on local server.
composer update
Next you should test application and add composer.lock to repository. And on PROD server you should run
composer install
composer update is checking if there are any new versions of the packages available within the limits of the versions given. This will unconditionally install new packages if they are eligible. After that you have to test.
composer install will install whatever is mentioned in the lock file, and if the currently installed packages are not the ones mentioned there, they will get uninstalled or updated.
Of course you want to "update" the prod application. But to update the packages, you run composer install which will update the packages to the TESTED state in the lock file - not to an UNTESTED state because newer versions did appear after you tested.