Consider moving sub-module specific composer.json requirements into suggest rather than require

One solution here, outside of suggest composer dependencies ((https://getcomposer.org/doc/04-schema.md#suggest) is to make sure that you can't install the module if the package is not available.

So in hook_requirements during phase install this should be possible asfaik (https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Extension...).

Ha yeah that's what I commented here https://www.drupal.org/project/ai/issues/3477368#comment-15798593 📌 Refactor Search API integration to pass more of the work to the VBD Provider Active - added to issue summary. But added some things that will stop working if we do this. So I think we need to decide together whether we even want to.

BTW I'm going to see if https://github.com/probots-io/pinecone-php will consider running tests against all major supported versions of php instead as the dependencies they have like saloon php are 8.1+. Bandage for this particular symptom though as we'll have this problem again with so many dependencies (I think it was tokenizers we first encountered the issue with some months back).

Coming from a Drupal Distribution we've found most of these issues to be the reason why we had to separated it to a different module.

Especially now with the move to project browser a lot more is very vanilla composer based, behind a UI, for site builders to use. The more you deviate from regular composer, the harder that will be to maintain I'd imagine. See for example: https://www.drupal.org/project/project_browser/issues/3300061 📌 [policy, no patch] Determine Composer validation rules for installing through Composer Fixed

We also have used hook_requirements for this in Open Social, basically because back than we still had people installing it without composer and we needed to have them install all the right packages. That could work I'd imagine, but means the DX suffers a bit, not sure how bad that is.

Potentially eventually recipes might help splitting this up in separate packages, to just have a set of packages running together.
E.g. if you want you can just have Milvus and Open AI working together, and only have them installed, helping the maintenance of those using the ai module as well. But I can imagine that's quite the topic to open, just thought i'd pitch that in here as well.

Yeah making this module as easy as possible would be ideal and given starshot, it may be a requirement that its usable in the WASM env + simpletest.me, in which case we cannot remove dependencies from composer.json.

For now I've made a PR to https://github.com/probots-io/pinecone-php/pull/13 and I suppose we could change the requirement to https://github.com/scotteuser/pinecone-php to unblock it for now.

As a side note I also have https://github.com/probots-io/pinecone-php/pull/11 open from a couple weeks ago.

Updated to my fork of it for now. We'll need to merge this I think to actually test composer update, but my manual tests both work:

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/scotteuser/pinecone-php"
        }
    ],
    "require": {
        "probots-io/pinecone-php": "dev-master"
    },
    "minimum-stability": "dev",
    "prefer-stable": true
}

and

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/scotteuser/pinecone-php"
        }
    ],
    "require": {
        "probots-io/pinecone-php": "dev-master"
    }
}

in php 8.1

All green now

Attempt 2 with packagist instead

Its now fine against -dev to `composer update drupal/ai` in a php 8.1 env

1. For the Pinecone specific case, created follow-up 📌 Revert to probots pinecone version once php8.1 PR is merged or php8.1 is no longer supported by Core Postponed
2. For other cases, we can tackle as we hit them

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