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

klausi created an issue. See original summary.

drumm’s picture

Project: Project » packages.drupal.org
Version: 7.x-2.x-dev » 7.x-1.x-dev
Component: Packages » Code
Related issues: +#2802009: Provide support for libraries and other non-drupal extensions (modules, themes etc)

https://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.

Mixologic’s picture

Coder 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.

Mixologic’s picture

Actually 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.

xjm’s picture

Title: 8.9.x-dev tarball INCLUDES CODER (!) because Composer packages.drupal.org definition incorrect for Coder 8.3.9 » 8.9.x-dev tarball INCLUDES CODER AS A MODULE (!) because Composer packages.drupal.org definition incorrect for Coder 8.3.9
Priority: Major » Normal
xjm’s picture

Priority: Normal » Major

Sorry for noise.

klausi’s picture

Priority: Major » Critical

Can 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.

greg.1.anderson’s picture

project_composer should simply exclude any library types or php_codesniffer types from the façade.

+1 ⭐

drumm’s picture

Assigned: Unassigned » drumm

Can you delete the Coder 8.3.9 release node on drupal.org?

We 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:

  • Move coder to be a Community project, which are https://www.drupal.org/project/project_drupalorg. While not semantically perfect, that would avoid packages.druopal.org processing as it is not a module (or theme).
  • Add a special case to packages.drupal.org to skip processing for coder.

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.

klausi’s picture

Just 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.

  • drumm committed 08ab404 on 7.x-1.x
    Issue #3135034 by klausi, drumm, Mixologic, xjm, greg.1.anderson: Skip...
  • drumm committed ba25da6 on 7.x-1.x
    Issue #3135034 by klausi, drumm, Mixologic, xjm, greg.1.anderson: Skip...
drumm’s picture

Status: Active » Needs review

This should be ready to go.

Today’s SaaS outage preventing more progress is https://bitbucket.status.atlassian.com/incidents/xlvfft1wg7dt

drumm’s picture

This has been deployed, and I am no longer seeing this behavior.

klausi’s picture

Thanks a lot, composer update drupal/coder --with-dependencies works normally again for me now.

Is there anything left to do here?

drumm’s picture

Status: Needs review » Fixed

This 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.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.