Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Coder uses semantic versioning now on drupal.org, but packages.drupal.org delivers the wrong meta information. drupal.org thinks Coder is a module, but it is a PHP library. drupal.org should respect the information in composer.json and not try to turn Coder insot a module. We are trying to find a workaround hack in the Coder issue #3134853: Composer packages.drupal.org definition incorrect for 8.3.9.
Proposed resolution
Fix drupal.org packaging so that it leaves Coder alone?
Comments
Comment #2
drummhttps://git.drupalcode.org/project/project_composer/-/blob/0a819b60c357d... is where this is happening. It would be a straightforward stopgap to put a special case in for coder.
This wouldn’t be the first special case for coder: https://git.drupalcode.org/project/project_composer/-/blob/0a819b60c357d.... Maybe that could be removed if this issue is resolved?
#2802009: Provide support for libraries and other non-drupal extensions (modules, themes etc) would be the non-stopgap fix.
Comment #3
MixologicCoder still lives at packagist.org. We either need to remove it from there, and offer it up on d.o. (and backport all the semver releases its had over time), or we need to not have it on packages.drupal.org, and rely solely on https://packagist.org/packages/drupal/coder to provide the metadata for people wishing to include it in their projects. If there are projects that use coder, but for some reason do *not* use packages.drupal.org, then removing it from packagist might be a bad idea. Who knows if thats a real thing or not.
Comment #4
MixologicActually the more I think about it, the more that Im convinced that packages.drupal.org *should not* offer up any normal php style packages. Those should all live at packagist.org . Now that we're running gitlab, packagist knows how to autoupdate from us, so, really, project_composer should simply exclude any library types or php_codesniffer types from the façade.
We already have a mechanism to auto create things at packagist via our subtree splitter, so perhaps when we enable library types in https://www.drupal.org/project/project_composer/issues/2802009, we add into the packaging step a drupal/
and autosubmit it to packagist.
Comment #7
xjmComment #8
xjmSorry for noise.
Comment #9
klausiCan you delete the Coder 8.3.9 release node on drupal.org? Maybe that helps so that 8.3.9 is loaded from packagist again like it was before with 8.3.8.
This is now critical since it breaks CI pipelines for many people in the Drupal community.
Comment #10
greg.1.anderson CreditAttribution: greg.1.anderson at Pantheon commented+1 ⭐
Comment #11
drummWe do not delete releases on Drupal.org, except in extraordinary circumstances. The release node locks the Git tag to a specific branch, so end users can rely on releases always containing the same code.
There are two good options I see right now:
While slightly less-clean, I’m implementing the second option for today. That keeps coder in the same place for other installation methods, like drush. Solving the general case, #2802009: Provide support for libraries and other non-drupal extensions (modules, themes etc) is a bigger project which won’t happen today.
Comment #12
klausiJust a note: Coder cannot be installed by drush, it requires Composer. The old Coder module is not supported anymore, so that is fine if it cannot be installed by drush anymore.
I'm happy with either solution otherwise.
Comment #14
drummThis should be ready to go.
Today’s SaaS outage preventing more progress is https://bitbucket.status.atlassian.com/incidents/xlvfft1wg7dt
Comment #15
drummThis has been deployed, and I am no longer seeing this behavior.
Comment #16
klausiThanks a lot,
composer update drupal/coder --with-dependencies
works normally again for me now.Is there anything left to do here?
Comment #17
drummThis is also fixed in https://www.drupal.org/project/drupal/releases/8.9.x-dev packaging. And no reports of anything but improvement have made it to me. So I think we can call this done.