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

Save unmodified file as xxx.old when applying a patch #569

Closed
4 tasks done
ArtemGoutsoul opened this issue Apr 17, 2024 · 4 comments
Closed
4 tasks done

Save unmodified file as xxx.old when applying a patch #569

ArtemGoutsoul opened this issue Apr 17, 2024 · 4 comments
Labels
enhancement New features, options, or other additions.

Comments

@ArtemGoutsoul
Copy link

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?

Workflow for updating patches is currently relatively complex. One needs to backup the modified files, remove the patches from config, run composer install, backup unmodified files, copy modified files from backup, modify them and regenerate the patches.

Describe your proposed solution(s)

Generate xxxx.old for each file to be patched before patching.

Having a backup as xxx.old will allow to easily modify the file and regenerate the patch using https://github.com/symplify/vendor-patches/

Describe alternatives

Currently the only alternative is the manual process described in the problem section.

Additional context

I made a related comment in symplify/vendor-patches
symplify/vendor-patches#22

@ArtemGoutsoul ArtemGoutsoul added the enhancement New features, options, or other additions. label Apr 17, 2024
Copy link

👋 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

Generating your patches like this seems really risky. Let's say I have symfony/console as a project dependency and I have some modification to https://github.com/symfony/console/blob/7.0/SingleCommandApplication.php. If I have a copy of that file and generate a patch using the differences between my copy of that file and whatever composer installs, how will I ever know specifically what that patch contains? What happens if symfony/console changes SingleCommandApplication.php after I take my copy of that file?

Also, isn't the end result of that process the same as if you just had a pile of files that you copied into place? e.g. you have overrides/symfony/console/SingleCommandApplication.php and you just cp overrides/symfony/console/SingleCommandAppliication.php vendor/symfony/console/SingleCommandApplication.php?

Either way, this is probably not a workflow that I can support in the core plugin, but that doesn't mean you can't do it. Composer Patches 2.x is extensible. You could write a composer plugin that subscribes to one of the Patch events and copies files around however you'd like. If you write a plugin to do that, let me know and we can set up a third-party plugins page in the Composer Patches docs to point people to it.

I'm going to close this issue, but feel free to reply if I've missed anything!

@ArtemGoutsoul
Copy link
Author

@cweagans I see your point, thank you for the answer!

Just to clarify: the overall flow comes from a project https://github.com/symplify/vendor-patches/ which essentially is a wrapper for your project and that simplifies the creation of patches. I'm only considering the special case when one needs to update an existing patch.

I already wrote own bash script that generates the .old files (i.e. the originals) based on the patches, it handles my use case pretty well: symplify/vendor-patches#22 (comment)

Of course the above only makes sense in a simpler cases, in anything more complex I would resort to maintaining an own fork anyway.

@cweagans
Copy link
Owner

I think there's some room to integrate more closely if that's the workflow you want to use. I just can't support it in the core plugin. Happy to answer questions if you decide to write another plugin to integrate this one and vendor-patches (or maybe even add the extra code to vendor-patches itself?)

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.
Projects
None yet
Development

No branches or pull requests

2 participants