szeidler / composer-patches-cli Goto Github PK

Currently there's no check if a package to be patched is actually installed.

A command like the following will run just fine, even if the package foo is not required.

composer patch-add foo "example patch" http://example.com/patch.diff

I'd suggest to add a "patch-remove" command. The syntax should be similar to the patch-add command, except you don't need the URL for non-interactive mode:

composer patch-remove <package> <description>

Use case:
I'm currently maintaining ~ 30 quite similar projects and need to perform automatic updates. I need to add a patch for a feature not yet commited to the package.

composer update drupal/* --with-dependencies
composer patch-add drupal/paragraphs "Issue 2907094 - Patch 7 - Paragraphs 1.8 does not work with Field Group 3.x-RC1": "https://www.drupal.org/files/issues/2907094_7_field_group_support.patch"

A few month later that patch was commited and that patch is no longer needed and does no longer apply. I'd need to create a script to to remove the patch from all projects, e.g. somehting like

composer patch-remove drupal/paragraphs "Issue 2907094 - Patch 7 - Paragraphs 1.8 does not work with Field Group 3.x-RC1"
composer require drupal/paragraphs:^1.9

Are there plans to make composer-patches-cli with composer-patches 2.0?
There is a beta version that can be tested: https://github.com/cweagans/composer-patches/releases/tag/2.0.0-beta1

Currently the version constraint does not allow installing it:

szeidler/composer-patches-cli 1.0.7    requires cweagans/composer-patches (^1.7) 

Is it possible to trigger a patch apply right after the patch-add command has run?

Thank a lot for this GREAT plugin, this is really really cool and I ❤️ it!!

Since switching to PHP 8 composer complains:

szeidler/composer-patches-cli[1.0.1, ..., 1.0.4] require php ^7.0 -> your php version (8.0.10; overridden via config.platform, same as actual) does not satisfy that requirement.

Is this plugin PHP 8 checked already and requires just a change in composer.json? Or are there larger steps to take?

Remote patches loaded from public URLs have security implications. It could be cool to have a command that is able to transform remote patches (with a URL) to download and rewrite them to a configurable patches folder.

• Add a new command composer patch-move-to-local
• Add a --directory=patches option or argument to define the folder where the local patches should be stored
• Will only apply to project patches, not patches of dependencies, that might be applied

This issue is somewhat related to #24, but not exactly the same.

When running composer patch-add or composer patch-remove, i get the following error:

$ composer patch-remove drupal/core "Patch title" 
               
The helper "dialog" is not defined.                               

patch-remove <package> <description>

I am running on Fedora with Composer 2.0.12

Currently the extension is based on external composer.patches.json file. It should also work with the standard behavior of having patches defined inline in the composer.json file.

Thank you for your work on this project.

I am curious if the current approach has support for patching the same project more than once.

When I run the following commands, I see messaging that discusses removing core (the target of the patch). If core gets removed for each patch, does it remove a previous patch? I am unclear from the current messaging.

composer patch-enable --file='patches.json'
The composer patches file was created.
The composer patches functionality was enabled successfully.

composer patch-add drupal/core "STM patch 564553073" "https://www.drupal.org/files/issues/2018-11-26/2991895-15.patch"
The patch was successfully added.
Gathering patches from patch file.
Removing package drupal/core so that it can be re-installed and re-patched.
  - Removing drupal/core (8.9.x-dev), source is still present in core
> Drupal\Composer\Composer::ensureComposerVersion
Deleting core - not deleted

composer patch-add drupal/core "STM patch 1665039650" "https://www.drupal.org/files/issues/2018-12-10/2938803-52.patch"
The patch was successfully added.
  - Removing drupal/core (8.9.x-dev), source is still present in core
Gathering patches from patch file.
Removing package drupal/core so that it can be re-installed and re-patched.
> Drupal\Composer\Composer::ensureComposerVersion
Deleting core - not deleted

The composer patch-add command requires a couple of arguments, which might . be hard to remember. Therefore the CLI should provide an interactive mode for missing or partly missing arguments in the patch-add command.

I tried providing local path (~/patch/mypatch.patch) for patch i am getting this error.

composer patch-add drupal/group "URL alias custom patch" "~/patch/mypatch.patch"

[Exception] Your patch url argument must be a valid URL.

I am not aware, if it is possible doing this with current code.

Thank you so much for this project and your efforts. It is very helpful.

I came across an issue that the CLI does not throw an error code during a composer update command.

This would be tremendously helpful to fire an exit code when a patch fails.

  - Installing drupal/core (8.8.x-dev): Source already present
  - Applying patches for drupal/core
    https://www.drupal.org/files/issues/2018-11-26/2991895-15.patch (STM patch 564553073)
   Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2018-11-26/2991895-15.patch

This was after I ran the following commands:

composer patch-add drupal/core "STM patch 564553073" "https://www.drupal.org/files/issues/2018-11-26/2991895-15.patch"
The patch was successfully added.
Gathering patches from patch file.
Removing package drupal/core so that it can be re-installed and re-patched.
  - Removing drupal/core (8.9.x-dev), source is still present in core
> Drupal\Composer\Composer::ensureComposerVersion
Deleting core - not deleted

composer patch-add drupal/core "STM patch 1665039650" "https://www.drupal.org/files/issues/2018-12-10/2938803-52.patch"
The patch was successfully added.
  - Removing drupal/core (8.9.x-dev), source is still present in core
Gathering patches from patch file.
Removing package drupal/core so that it can be re-installed and re-patched.
> Drupal\Composer\Composer::ensureComposerVersion
Deleting core - not deleted

I used composer patch-add to add a patch, which succeeded, but some other packages got updated at the same time, which rather surprised me!

In my case, the package I was patching was drupal/toolbar_language_switcher and the following packages got updated:

• phpdocumentor/type-resolver
• phpstan/phpdoc-parser
• phpunit/phpunit
• psr/http-factory
• symfony/var-dumper

This seems amazing to me - even if these updates are allowed within the version constraints in composer.json, and even if those packages might be dependencies of the patched package (direct or indirect), surely adding a patch should only affect the patched package. I see that PatchAddCommand::execute() uses ->setUpdateAllowTransitiveDependencies(Request::UPDATE_LISTED_WITH_TRANSITIVE_DEPS_NO_ROOT_REQUIRE), could that just use Request::UPDATE_ONLY_LISTED instead? Though even that could unintentionally update the patched package itself too, I imagine? But that would at least reduces the potential problem.

FWIW, I avoided the issue by adding --no-update to my composer patch-add command, and then just ran composer update --lock, to successfully apply just the patch.

(Sorry for initial empty issue)
Since version 1.5 composer can handle running in subdirectories, prompting the user with a ,essage like:

No composer.json in current directory, do you want to use the one at /path/to/composer? [Y,n]?

I believe this plugin should use the same approach. As of now if run in a subdirectory an error is returned:

Composer could not find a composer.json file in /path/to/composer/subdir
To initialize a project, please create a composer.json file as described in the https://getcomposer.org/ "Getting Started" section

Since I add patches from MRs on the drupal.org gitlab and those are subject to change I would like to have the option to download that patch locally. I was thinking something around the lines of
composer patch-add --download-path=patches/my-patch.patch
That fetches the patch from the URL and saves it.

Do you think this can be useful?
I am willing to do the coding part but I don't want it to be a dangling PR for a long time if it is not an interesting feature to have.

The cweagans/composer-patches project allows patches to de declared in a separate file, or an extra.patches section of the root composer.json

The README for this CLI tool implies that using a separate patches file is necessary. Is that correct?

My steps:

• I already have several patched drupal contrib modules. The patches are declared in my composer.json file, in the extra.patches section.
• Then I required szeidler/composer-patches-cli
• Running composer patch-list works. It lists all the projects I already use patches for.
• composer patch-add didn't work... [Exception] Patch file was not defined in your composer.json.
• composer patch-enable. Now a composer.patches.json file has been created.
• composer patch-add seems to work now. The patch is mentioned in composer.patches.json
• But the patch doesn't get applied ever.
• I deleted the entire extra.patches section of my composer.json
• now the patches defined in composer.patches.json get applied.

So it seems that I can only use place for declaring patches. I think that may be a limitation of cweagans/composer-patches, which is fine.

But does composer-patches-cli only work with a separate patches file?

I have some problems when I add composer-patches-cli to any of my projects. It seems that my project loses its paths and files cannot be found by composer anymore.

I did some debugging and I noticed that the problem is with the code at PatchBaseCommand.php. I also noticed that PatchBaseCommand changes the working directory but this code is redundant cause it is present in Composer since version 1.5.0. See https://github.com/composer/composer/blob/1.5.0/src/Composer/Console/Application.php

I'm using Composer 1.10.7 and I tried to include composer-patches-cli on Drupal projects.
My suggestion is to remove the code introduced by PatchBaseCommand::changeWorkingDirToComposerRoot(), which fixes the issue while the functionality is still being provided by Composer.

Maybe this dialog (and following) should be put as a Trait so can be shared between the two patch-add and patch-remove classes?
Or else have a common ancestor like PatchFileManipulatorAbstractCommand ?

Having a common ancestor could also help for adding/removing the patch with sharing all the options, because basically the two commands are very very similar.

Originally posted by @esolitos in #12