Remove the ability to configure the path to Composer

Two questions about this.

1. The MR currently completely removes the configuration for composer, as an experimental module that's fine as far as core's concerned.

However package_manager is already used in production by Drupal CMS sites (or other sites using project browser/automatic updates) and those sites may be relying on having configured the composer path. Also depending on the host and who installed the site, running composer require composer/composer from the command line may not be an easy option.

So I'm wondering if this needs a two step process.

1. Keep the configured path as a final fallback if local and PATH composer can't be found. When this is the case, we could have a hook_requirements() warning telling people they need to fix the problem, but it wouldn't immediately break.

2. Later on (maybe for 12.0.0) remove the configuration entirely as the MR currently does.

2. It might be possible for automatic updates or project browser to add an update that detects whether composer is found locally or in PATH, and if it's not, runs composer require composer/composer via package manager to install a local composer. Once the local composer is installed, the site would then no longer be using the configuration any more and it would be safe to remove. If automatic updates/project browser introduces that update path before Drupal 12 support is added, it would then more or less guarantee that sites continue to work once the configuration is removed.

The above isn't necessary for core, but I think it probably needs discussion with the Drupal CMS team whether that's something that's worth attempting.

I was thinking along similar lines. It probably makes sense to remove the executables structure from config schema, so that it can stay in existing sites but is no longer considered "valid" config.

Meanwhile, the executable finder can use it as a final fallback, and trigger a deprecation warning. We can also do a separate requirements error (or warning, I guess) that having a configured path to Composer is deprecated and will not be supported in Drupal 12.

catch → credited benjifisher → .

Crediting @benjifisher for slack discussion related to this.

Reading summary and MR, I wonder if a setting fallback (instead of having to install it via composer or adjust the PATH) for finding composer would also make sense. Seems easier to migrate from the config to a setting than the other choices. I don’t see how it’s worse from a security standpoint. We already have to trust settings isn’t writable by malicious actors.

I agree with @dww and have added the settings-based fallback.