-
-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
composer install skipping patch process #583
Comments
How are you doing this? Just adding it manually to composer.json and then ___ ? You should not have to manually delete anything or run composer update to get composer-patches to work. I recommend following this process: https://docs.cweagans.net/composer-patches/usage/recommended-workflows/#add-a-patch-to-your-project I know for sure that Pantheon will install patches properly. If you want to see how it'll behave, commit your changes to composer.json, composer.lock, and patches.lock.json and push it to the repo. Then, clone a completely fresh copy of the Git repo and run a |
I created patches.json and put the patch in there. I already had composer-patches installed and enabled from previous usage. I did bump the version to the latest 2.x beta from 1.x. When I ran composer update it created patches.lock.json after implementing rhe patch. No changes were ever established on composer.lock. Maybe that's the issue? Why would changes be made to that file? I'm not actually updating the patched module (page_manager), I'm patching the existing installed version that composer.lock already knows about. Hence a basic install sees the lock version is already installed and decides "do nothing", bypassing the patch process. I will try your linked workflow and report back. I thought I did something similar but can't be totally sure so I will try again. |
@cweagans Here is what I did:
It did not work.
In fact, this procedure didnt really change the state of my repo in meaningful ways. Step 8 is confusing. No changes were made to As the output above shows, an unchanged Does any of this make sense? The issue is not with Pantheon. There may not even be an issue with composer or I may try dropping the dependency and patch, commiting/deploying that change, then adding back the dependency and patch and the generated files from the documentation steps, and see if that causes Pantheon to trigger a fresh install of the dependency in question, which will then trigger the patching. If this understanding of the situation is correct, it should probably be detailed in the documentation. I will report back when I test tomorrow. But I am really eager to test any further ideas you have or provide any further info that could help debug the situation. |
My analysis seems to be correct. Once I removed the package then re-added it, the patch was triggered. However, I had to break this into two separate commits to make it work on Pantheon, the reason being what the same was what I've explained above---if I remove it and re-add it, then the state it the same, there is nothing to commit, and composer determines there is nothing to do, including patching, because the installed version is the locked version. This should probably be in the documentation somewhere, but it's a rather complex issue to put into words. Maybe something like:
|
@cweagans do you want me to close this? Does any of this make sense? If so, do you think it should be documented a la my comment above? |
Need some time to grok it all. I think you might be doing something wrong but I want to understand more fully before I make that assertion :) |
K. I think the question is: does patching get triggered or skipped if "composer install" determines there is nothing to do? If triggered: I must be doing something wrong or have some environmental issue. If skipped: this should be documented |
If One thing that you could do in your project as a test is to set up a post-install script that runs {
"extra": {
"scripts": {
"post-install-cmd": [
"@composer patches-repatch"
]
}
}
} That should trigger on Pantheon too. It might add a little bit of extra time to your deploys, but it shouldn't be too much. If that makes things behave a little closer to what you're expecting, it might be worth investigating adding something that subscribes to the "post-install-cmd" event in the plugin itself that somehow checks if patches are applied. Or maybe there's a setting that makes composer patches more aggressive about re-applying patches? If this is specific to how Pantheon handles their environments, you might be able to set up a Quicksilver script (https://docs.pantheon.io/guides/quicksilver/install-script) that just runs In the past, there were a lot of complaints about composer patches just blowing away an entire directory (which could have contained work-in-progress if somebody was e.g. contributing to a Drupal module). This was done in the interest of ensuring that patches were always applied no matter what. I'm not really sure what to do here - it seems like re-patching automatically doesn't work for some people and not re-patching automatically doesn't work for others. Maybe this is just a config option that needs to be exposed - if true, then |
It sounds like my analysis is correct then, and maybe it should be documented. The situation being: if you want to patch your current locked dependency, without updating, it will not work unless you remove and then reinstall the dependency, or use patches-repatch I tried a similar post script, but it caused an infinite loop. I'm beyond the issue on my end. I removed the dependency, deployed that to pantheon, then re-added it, and deployed that. The patch was trigger and all is well |
Verification
composer self-update
)composer update cweagans/composer-patches
)What were you trying to do (and why)?
I am deploying Drupal to Pantheon, a popular hosting service.
My Pantheon and local are on the latest version of all dependencies and are in sync. I'm running
2.0.0-beta2
ofcomposer-patches
.I then introduce a new patch on my local. While
composer install
does nothing, skipping the patch process withNothing to install, update or remove
, I can hack around this by deleting the targetweb/modules/composer/page_manager
composer managed directory and then runningcomposer update
. This re-installspage_manager
and applies the patch without issue. Likewise,composer patches-repatch
works.But Pantheon doesn't do this. Their deployment process runs "composer --no-interaction --no-progress --prefer-dist --ansi install". As noted above on my local, the output of this command also says
Nothing to install, update or remove
. The patching mechanism isn't triggered at all.I'm happy to provide more info if you tell me what will be helpful.
What happened? What did you expect to happen?
The patch process was not executed.
I expected the patch to be applied, as it is successfully applied during
composer patches-repatch
Contents of
composer.json
The text was updated successfully, but these errors were encountered: