Include dependency to DKAN in contrib module info.yml

[stefan-korn]

How can I include a dependency to DKAN (or even a submodule like metastore) in a info.yml for a contributed module?

I can write dependency in info.yml like on of this:

dependencies:
  - dkan:metastore
  - metastore:metastore
  - drupal:metastore

This will work if the module is only a local module. But if it is contrib module the Drupal composer packaging does somehow translate the dependencies from info.yml to composer dependencies, thus composer require drupal/custom_module will require dependency like drupal/metastore. But it cannot find drupal/metastore in the drupal composer packages (because DKAN is on Github), resulting in composer message like this

drupal/metastore * -> could not be found in any version, there may be a typo in the package name.

This seems to be the case no matter how the dependency is written in the info.yml. Drupal seems to do some magic here: https://drupal.stackexchange.com/questions/302656/how-is-composer-including-a-dependent-module

Does anybody know a solution to this problem?

PS: I can include dependency to DKAN in composer.json of the contrib module. But this will only composer install DKAN but does not have an effect on the order of module installation in Drupal.

[paul-m]

Drupal's Composer facade does a lot of magic in order to discover submodules with in the composer package, so it requires the correct composer package. (As an example, if you say composer require drupal/file_example Drupal's composer repo will install drupal/examples.) However, this doesn't happen for external dependencies, such as DKAN.

If you're making a Drupal-hosted contrib module that needs DKAN, you should add a composer.json file to it that requires getdkan/dkan. This gets you the entire DKAN package, including metastore. Just treat it like any other external dependency: https://www.drupal.org/docs/develop/using-composer/managing-dependencies-for-a-contributed-project

If the contrib module needs a specific DKAN module to be enabled at runtime, then as you point out above, use the info.yml to declare dependencies, so that Drupal will then try to enable that module on install.

[stefan-korn]

@paul-m : thanks for your answer.

I get it to work like you described making composer require getdkan/dkan with composer.json in the contrib module.

But doing this:

If the contrib module needs a specific DKAN module to be enabled at runtime, then as you point out above, use the info.yml to declare dependencies, so that Drupal will then try to enable that module on install.

does always end up in composer searching for drupal/metastore (for example) and not finding this. The Drupal magic seems to add every dependency in the modules info.yml as a composer dependency as well, but always searching only in the "drupal" composer namespace.

[paul-m]

Last I heard, if you supply a composer.json file in your contrib module, the drupal composer repo won't try to add it from info.yml. That may have changed since I looked into it though.

[stefan-korn]

There are issues at the Composer facade that seem to address this too, like:
https://www.drupal.org/project/project_composer/issues/2864379
https://www.drupal.org/project/project_composer/issues/3304661

But I get no clue from this right now. I am not sure if I can formulate the info.yml dependency to not have Composer facade look in drupal/..., tried like "module", "drupal;module", "module:module", "package:module", but all seem to end up looking for drupal/module in composer.

My issue was with installing DKAN from a profile and getting the wrong installation order of contributed module dependening on DKAN and DKAN itself. Now I solved this by installing the contributed module depending on DKAN in hook_install in the profile. This solves it for me now, because this way the contributed module surely comes after DKAN.

But in general there seem to be an issue in this process. Find it kind of opaque that Drupal is transforming the info.yml dependencies in composer dependencies. Would be cleaner to just rely on composer.json or at least to not look in info.yml if there is a composer.json in the module like you proposed or supposed.