Skip to content
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

Another kind of applying patch failing silenty #578

Open
4 tasks done
mfrieling opened this issue Jun 4, 2024 · 3 comments
Open
4 tasks done

Another kind of applying patch failing silenty #578

mfrieling opened this issue Jun 4, 2024 · 3 comments
Labels
enhancement New features, options, or other additions. help-wanted We want to add this to the project. Contributions welcome!

Comments

@mfrieling
Copy link

mfrieling commented Jun 4, 2024

Verification

  • I have updated Composer to the most recent stable release (composer self-update)
  • I have updated Composer Patches to the most recent stable release (composer update cweagans/composer-patches)
  • I am using one of the supported PHP versions (8.0+)
  • I have searched existing issues and discussions for my idea.

Is your feature request related to a problem?

I just had another case of a patch not being applied without any error message or information, aka silently. First I tried to apply the patch manually with git apply which failed as well, but patch -p1 , [patch-file] worked. After reading different issues why composer-patches uses git apply and not the patch command I decided to debug into composer prp if I can find the cause.

That was an easy one as it turned out being a typo in the package name inside composer.patches.json. So no bug at all, just a stupid (but time-consuming user error).

Describe your proposed solution(s)

As this might happen to other people as well, please add some useful output as warning or notice if a patch cannot be applied for different reasons, i. e.:

  1. The package for which a patch is defined/locked cannot be found/is not installed.
  2. The patch file is not downloadable/readable/...
  3. Best possible error message returned from the patcher instance

No. 2 and 3 might already be implemented, I diidn't check the code for them. But no. 1 is the use case of this feature request.

If that might be too annoying consider putting these outputs behind a verbose flag.

Describe alternatives

No response

Additional context

No response

@mfrieling mfrieling added the enhancement New features, options, or other additions. label Jun 4, 2024
Copy link

github-actions bot commented Jun 4, 2024

👋 Thanks for the idea! Please remember that this is an open source project - feature requests may or may not be implemented, and if they are, the timeline is unknown. If you need a guaranteed implementation or timeline, sponsorships are welcome!

@cweagans
Copy link
Owner

cweagans commented Jun 4, 2024

2 and 3 are already implemented, I think.

1 seems like a good idea as an opt-in behavior. I probably won't get to it in the near future -- should be pretty straightforward though. PRs welcome :)

  1. After patches are resolved here:
    $resolver->resolve($patchCollection);
    }
    return $patchCollection;
  2. Get the list of installed packages: $this->composer->getLocker()->getLockedRepository()->getPackages()
  3. Loop through the list of patches, get the package to which they apply, and see if that package is in the list of installed packages. If you come across one that isn't present and the config flag is set in the main plugin, throw an exception.

@cweagans cweagans added the help-wanted We want to add this to the project. Contributions welcome! label Jun 4, 2024
@mfrieling
Copy link
Author

Thanks @cweagans. I would have done it here by changing the array_filter callback because when repatching is where the strange thing (patch silently not applied) happens:

$patched_packages = $patchCollection->getPatchedPackages();
$packages = array_filter($localRepository->getPackages(), function ($val) use ($patched_packages) {
return in_array($val->getName(), $patched_packages);
});

But it is probably better to do it when relocking as you suggested. At the moment I don't have time for it either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New features, options, or other additions. help-wanted We want to add this to the project. Contributions welcome!
Projects
None yet
Development

No branches or pull requests

2 participants