Problem/Motivation

Disclaimer: Not sure that is the right project to post this.

  1. Add a module as dist (using a stable, beta, alpha version) in your composer.json.
  2. Create a patch that fixes the .info.yml file.
  3. Add the patch in composer.json and update.

In most of the cases the paching will fail because the content of the dist .info.yml contains also the packager script lines. The patch is build every time using the source, where those lines doesn't exist.

Proposed resolution

The .info.yml file is part of the codebase, it should not be altered by any script.

Long term solution

Move these package info in their own file that should be added by the the packager script, as LICENSE.txt is added.

Quick fix

Before the line # Information added by Drupal.org packaging script on ... add enough empty lines, so that the changed hunk doesn't interfere. Will still be a problem with the .info.yml files of sub-modules being deleted.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

Comments

claudiu.cristea created an issue. See original summary.

dww’s picture

dww
we/he/they
commented
Related issues: +#3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core, and allow modules to be compatible with Drupal 8 and 9 at the same time, +#2313917: Core version key in module's .info.yml doesn't respect core semantic versioning, +#2641658: Module version dependency in .info.yml is ineffective for patch releases, +#2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches

Good issue, hard to classify. There's been talk of this before, but I don't remember exactly where.

The quick fix would be a feature request for https://www.drupal.org/project/issues/drupalorg

The long term fix would need changes both on the d.o side and in core itself (since core would have to know to look in *.version.yml (or whatever) for the version info, instead of looking in *.info.yml).

Adding a bunch of related issues that are high priority for D9 that would be touching very similar code.

How exactly you wish to navigate all this complexity with this particular issue is up to you. Maybe make it a META plan and open sub issues in the various places for the various short vs. long term aspects?

Good luck!
-Derek

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

claudiu.cristea’s picture

claudiu.cristea
Primary language Romanian
Location Arad 🇷🇴
commented
Related issues: +#3066468: Packaging info from .info.yml often creates conflicts when patching (ddo)

@dww, thank you. I've opened #3066468: Packaging info from .info.yml often creates conflicts when patching (ddo).

drumm’s picture

drumm
he/him
Location NY, US
commented

Does composer patches have a way to specify -C<n> to reduce or remove the required context match?

As dww said:

The long term fix would need changes both on the d.o side and in core itself (since core would have to know to look in *.version.yml (or whatever) for the version info, instead of looking in *.info.yml).

We can’t just remove the data and break update module.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

adamzimmermann’s picture

adamzimmermann commented

I ran into this issue recently. Was great to see this issue and that others are aware of this and thinking about it.

https://www.drupal.org/project/publication_date/issues/2983348#comment-1...

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

andrewmacpherson’s picture

andrewmacpherson commented

Re. #5:

Does composer patches have a way to specify -C to reduce or remove the required context match?

No, it doesn't.

It tries two different methods of patching. For projects which have a .git directory (because of --prefer-source, or whatever) it attempts to apply the patch using git. The relevant line is in \cweagans\Composer\Patches::applyPatchWithGit():

$patched = $this->executeCommand('git -C %s apply %s %s', $install_path, $patch_level, $filename);

For projects which don't have a .git directory, it falls back to a patch command:

        if ($patched = $this->executeCommand("patch %s --no-backup-if-mismatch -d %s < %s", $patch_level, $install_path, $filename)) {

These are from the 1.6.7 release of cweagans/composer-patches.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

At a certain point it might be worth switching to https://github.com/vaimo/composer-patches instead of cweagans/composer-patches as vaimo's version has more options available.

Disclaimer: I haven't tested vaimo/composer-patches yet, but the docs suggest it might help.

adamzimmermann’s picture

adamzimmermann commented

I documented the solution that I used as a short term work-around. Hopefully this helps others while we decide on a long-term solution.

https://chromatichq.com/blog/patching-info-files-composer

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

gaëlg’s picture

gaëlg
he/him
Primary language French
Location Lille, France
commented

@adamzimmermann, great tip, thanks!

pieterdt’s picture

pieterdt commented

indeed, great tip in #11! much appreciated you took the time to document a workaround!

roy84’s picture

roy84 commented

Had a hard time patching a module.info file...

#11 worked! Thanks for that!

Is there any option to work with a version.info file, to keep clean module.info files?

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

orakili’s picture

orakili commented

I encountered this issue when trying to add modules that are not yet compatible with Drupal 10 but have a compatibility patch.

I created this tiny composer plugin https://packagist.org/packages/orakili/composer-drupal-info-file-patch-h... as a companion of https://packagist.org/packages/cweagans/composer-patches that registers to the patch events provided by this plugin and removes the data added to the `info.yml` by the Drupal packaging script before patching and add it back after the patch.

I'm using that together with https://packagist.org/packages/mglaman/composer-drupal-lenient to install D9 modules and apply their D10 compatibility patch, on D10 sites.

matsbla’s picture

matsbla commented
Priority: Normal » Major

I also have problems to update my sites to D10, there are patches ready to be applied, but am unable to patch my modules using composer. I think this issue should be escalated to major, as it makes it difficult to update sites to next drupal version.

edmund.dunn’s picture

edmund.dunn commented

@orakili package in #22 works well. I tried the patcher from vaimo, but it wasn't applying all of the patches cleanly.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

rasikap’s picture

rasikap commented

@orakili, the package does work but not for all modules. I tried patching sfweb2lead_webform but it fails.

watergate’s picture

watergate commented

@orakili, thanks for the Composer plugin. It helped me/us a lot!

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.