tbachert/spi requesting trusted action

Looking in composer.lock, it seems tbachert/spi is required by a new version of open-telemetry/sdk which is required by new core-dev 10.3.6

$ composer why tbachert/spi
Cannot load Xdebug - it was already loaded
open-telemetry/sdk 1.1.0 requires tbachert/spi (^1.0.1) 

$ composer why open-telemetry/sdk
Cannot load Xdebug - it was already loaded
drupal/core-dev              10.3.6 requires  open-telemetry/sdk (^1)      
open-telemetry/api           1.1.0  conflicts open-telemetry/sdk (<=1.0.8) 
open-telemetry/exporter-otlp 1.1.0  requires  open-telemetry/sdk (^1.0) 

A release note would be nice - did not see one?

This issue queue is not for Drupal core. This project just contains patches that should applied to Drupal core.

where should it go @avpaderno?

If those are dependencies of Drupal core, it should go on the Drupal project.

Going down the rabbit hole where this came from. open-telemetry was originally added in 📌 Add open-telemetry/sdk and open-telemetry/exporter-otlp as dev dependencies Active , but it has no mention of this composer plugin that now has snuck in.

This Composer plugin didn't exist at the time that issue merged.

It's fine to set it to allowed false because it only runs during tests. Not sure where would be best to document this. I guess a change record would be a start.

We might want to file an upstream issue asking whether it really needs to be a dependency too though, or at least find the upstream commit where it was added.

👍

I did do some spelunking through commit logs, but haven't yet been able to pinpoint how and why this is suddenly triggering. I didn't get further than "this has always been here" (but a second opinion would certainly be welcome). I did not compare to when Composer actually started asking permission to run plugins, that may be a factor too.

Composer started asking for permissions for plugins a long time ago. It's been at least two years.

This occurred when open-telemetry/sdk went from 1.0.8 to 1.1.0, which added the dependency on tbachert/spi.

Is there any downside to choosing yes when presented with this?

To support PHP 8.4 upgrade is required, so I filed upgrade issue 📌 Upgrade open-telemetry packages for PHP 8.4 Active

So this one becomes follow-up

Hi all. I'm one of the maintainers from opentelemetry-php, how can I help here? tbachert/spi is a package developed by one of the opentelemetry-php core contributors which we have started to use to configure parts of opentelemetry. I guess think of it as dependency injection, based on configuration in composer.json - the reason for the plugin is to compile/generate an output file of SDK dependencies.

Right now, opentelemetry should work just fine with that plugin disabled (it's currently only used by a new declarative configuration feature that's still being actively developed).

@brettmc thanks for commenting.

The main issue for us is that new composer plugins prompt everyone using core's development dependencies (which is somewhere between hundreds to thousands of people per month) to allow the plugin or not, and it's not clear from the composer message (not opentelemetry's fault) where the new plugin is added from or whether they should allow it or not.

I think documenting this is the best we can do and your explanation helps.

We've integrated opentelemetry into our phpunit testing framework for performance testing (not what it's designed for as such, it powers https://gander.tag1.io/?orgId=1&refresh=30s) but even for the tests that can use it, it's not a required dependency, just sends data when configured to, so it should be safe for everyone to leave this disabled unless they're specifically working with the opentelemetry integration, but it sounds like it's not going to be necessary even then for a while.

Not sure where's best to document this but we could start with just a change record for now. Maybe a short note on https://www.drupal.org/about/core/policies/core-dependency-policies-and-... →

I filed https://github.com/Nevay/spi/pull/5 to prevent updating core's vendor hardening

@andypost:

I filed https://github.com/Nevay/spi/pull/5 to prevent updating core's vendor hardening

I think what you mean is that we will not need to update the config for drupal/core-vendor-hardening if that PR is merged. Either way, nothing prevents us from updating it.

I updated the issue description (Remaining tasks) based on Comments #19 and #20.

@benjifisher yes, exactly it

Added a draft CR. Will someone review it?

Instead of documenting this on https://www.drupal.org/about/core/policies/core-dependency-policies-and-... → , I added a link to list of issues tagged, 'approved dependency evaluation'. That way people can find the original issue easily enough and the Policy page won't need a change to remove the note later. I also added the link to the JavaScript dependency page.

I made some small edits.

Like the link being added to https://www.drupal.org/about/core/policies/core-dependency-policies-and-... → that just list the issues. Believe that should help in the future

Reviewed the CR attached https://www.drupal.org/node/3492353 → and reads fine to me. Nice update to mention it's disabled by default.

Ok, let's publish the CR and close this.

@smustgrave, @cilefen, thanks.

I published the CR and updated credit (including myself for the CR).

Thanks!