Erroneous Unresolved dependency with missing version in info file

The problem is that drupal core doesn't recognize "drupal/search_api": "1.x-dev" as newer then 8.x-1.2.
If you replace it by "drupal/search_api": "~1.2" it should work.
I think this is a core issue and I guess there's an existing issue for that. But I can't find it now. Therefore I move this issue to core.

Try this: https://www.drupal.org/project/composer_deploy

This seems a duplicate of #2538090: Allow the Update Manager to automatically resolve Composer dependencies.

@cilefen: I disagree.

The problem is unrelated to composer. If git clone a module and try to install it, you run in this issue. Composer isn't involved here.
The git checkout has no version in info.yml.
Nevertheless as the latest version it should satisfy the dependency for >=8.x-1.2 declared in a different modules info.yml.

You specifically wrote "UI" in the issue summary so I was confused. So this is not the update module, or the install system, it's perhaps the extension system but I am still unsure as to what Drupal core has to do with this issue.

Please add steps to reproduce.

Reproduce without composer:

1. Install drupal 8.3.x or 8.4.x from tar.gz download and cd into modules/contrib
2. git clone --branch 8.x-1.x https://git.drupal.org/project/search_api.git
3. wget https://ftp.drupal.org/files/projects/search_api_solr-8.x-1.0.tar.gz

Search API Solr Search is not installable via UI because of an unmet dpendency. But the latest git clone version of search_api should obiously resolve the depency.

drupal_check_incompatibility($v, $current_version) for search_api_solr gets these parameters for $v and $current_version:

array(3) {
  ["name"]=>
  string(10) "search_api"
  ["original_version"]=>
  string(12) " (>=8.x-1.2)"
  ["versions"]=>
  array(1) {
    [0]=>
    array(2) {
      ["op"]=>
      string(2) ">="
      ["version"]=>
      string(3) "1.2"
    }
  }
}
string(0) ""

https://www.drupal.org/project/composer_deploy solves the issue if you use composer to get a dev version. But it doesn't solve it for direct git clones, at least if they don't contain a composer.json.

I ran into a similar sounding warning updating from Search API Solr version 2.7 to 3.3. The only module I use dev-version of is Views data export, which has a test dependency on Search API, could that be why?

test_dependencies:
  - xls_serialization:xls_serialization
  - search_api:search_api

Anyway, I went ahead with the update, and everything seems to work fine. I am including it here in case anyone else ends up finding this issue, searching for words like "Unresolved dependency" and "Search API":

$ drush updatedb
 [error]  Search API Solr requires this module and version. Currently using Search API version  (Currently using Unresolved dependency Search API (Version >=8.x-1.14 required))

 Requirements check reports errors. Do you wish to continue? (yes/no) [yes]:
 > yes

 ----------------- ----------- --------------- --------------------------------
  Module            Update ID   Type            Description
 ----------------- ----------- --------------- --------------------------------
  search_api_solr   8300        hook_update_n   Migrate Solr backends to the new unified Solr backend.
  search_api_solr   8301        hook_update_n   Field types clean-up.
  search_api_solr   8302        hook_update_n   Re-install language-specific field types to enable the new spellcheckers.
  search_api_solr   8303        hook_update_n   Remove obsolete setting in config.
  search_api_solr   8304        hook_update_n   Convert site_hash from setting to state.
  search_api_solr   8305        hook_update_n   Add Dutch nouns and improve stemming for Dutch language.
  search_api_solr   8306        hook_update_n   Replace deprecated Solr filters by their successors for Solr 7.
  search_api_solr   8307        hook_update_n   Avoid redundant text files in generated Solr config files.
  search_api_solr   8308        hook_update_n   Configure multilingual features individually per index.
  search_api_solr   8309        hook_update_n   Solarium 5 adjustments. Warning! If you have overwritten the connection settings, don't forget to adjust the 'path'. See the release notes for details.
  search_api_solr   8310        hook_update_n   Enable language-specific collations.
  search_api_solr   8311        hook_update_n   Add the Polish diacritics to the language configs. Unset the obsolete min and  max parameters from the  CJKWidthFilter of the spellchecker (mainly for Japanese).
  search_api_solr   8312        hook_update_n   Add language-specific unstemmed field types.
  search_api_solr   8313        hook_update_n   Distinguish between simplified and traditional Chinese.
  search_api_solr   8314        hook_update_n   Enable language-unspecific collation.
  search_api_solr   8315        hook_update_n   Avoid Solr exceptions when multilingual spell checking by using unified  analyzer.
  search_api_solr   8316        hook_update_n   Use Ukrainian lemmatization instead of Russian   SnowballPorterFilterFactory.
  search_api_solr   8317        hook_update_n   Replace erroneous Swedish default field type.
  search_api_solr   8318        hook_update_n   Replace solr.MorphologikFilterFactory by solr.MorfologikFilterFactory.
  search_api_solr   8319        hook_update_n   Fix Solr 6 Czech Field Type and improve spellcheckers.
  search_api_solr   8320        hook_update_n   Fix 2.x to 3.0 upgrade path of spellcheck components.
  search_api_solr   8321        hook_update_n   Fix Chinese Field Types.
  search_api_solr   8322        hook_update_n   Fix Thai and Turkish Field Types.
  search_api_solr   8323        hook_update_n   Fix path to ukrainian.dict for Solr 8.2.0.
  search_api_solr   8319        post-update     Install new Solr Field Types and uninstall search_api_solr_multilingual.
 ----------------- ----------- --------------- --------------------------------

 Do you wish to run the specified pending updates? (yes/no) [yes]:
 > yes

>  [notice] Update started: search_api_solr_update_8300
>  [notice] Update completed: search_api_solr_update_8300
>  [notice] Update started: search_api_solr_update_8301
>  [notice] Update completed: search_api_solr_update_8301
>  [notice] Update started: search_api_solr_update_8302
>  [notice] Update completed: search_api_solr_update_8302
>  [notice] Update started: search_api_solr_update_8303
>  [notice] Update completed: search_api_solr_update_8303
>  [notice] Update started: search_api_solr_update_8304
>  [notice] Update completed: search_api_solr_update_8304
>  [notice] Update started: search_api_solr_update_8305
>  [notice] Update completed: search_api_solr_update_8305
>  [notice] Update started: search_api_solr_update_8306
>  [notice] Update completed: search_api_solr_update_8306
>  [notice] Update started: search_api_solr_update_8307
>  [notice] Update completed: search_api_solr_update_8307
>  [notice] Update started: search_api_solr_update_8308
>  [notice] Update completed: search_api_solr_update_8308
>  [notice] Update started: search_api_solr_update_8309
>  [notice] Update completed: search_api_solr_update_8309
>  [notice] Update started: search_api_solr_update_8310
>  [notice] Update completed: search_api_solr_update_8310
>  [notice] Update started: search_api_solr_update_8311
>  [notice] Update completed: search_api_solr_update_8311
>  [notice] Update started: search_api_solr_update_8312
>  [notice] Update completed: search_api_solr_update_8312
>  [notice] Update started: search_api_solr_update_8313
>  [notice] Update completed: search_api_solr_update_8313
>  [notice] Update started: search_api_solr_update_8314
>  [notice] Update completed: search_api_solr_update_8314
>  [notice] Update started: search_api_solr_update_8315
>  [notice] Update completed: search_api_solr_update_8315
>  [notice] Update started: search_api_solr_update_8316
>  [notice] Update completed: search_api_solr_update_8316
>  [notice] Update started: search_api_solr_update_8317
>  [notice] Update completed: search_api_solr_update_8317
>  [notice] Update started: search_api_solr_update_8318
>  [notice] Update completed: search_api_solr_update_8318
>  [notice] Update started: search_api_solr_update_8319
>  [notice] Update completed: search_api_solr_update_8319
>  [notice] Update started: search_api_solr_update_8320
>  [notice] Update completed: search_api_solr_update_8320
>  [notice] Update started: search_api_solr_update_8321
>  [notice] Update completed: search_api_solr_update_8321
>  [notice] Update started: search_api_solr_update_8322
>  [notice] Update completed: search_api_solr_update_8322
>  [notice] Update started: search_api_solr_update_8323
>  [notice] Update completed: search_api_solr_update_8323
>  [notice] Update completed: search_api_solr_post_update_8319
>  [warning] Message: A new Solr field type has been installed due to configuration changes. It is
> advisable to download and deploy an updated config.zip to your Solr server.
>
 [success] Finished performing updates.

I'm experiencing this when the module lacks a version.
linkit.info looks like this:

name: Linkit
type: module
description: 'Provides an easy interface for internal and external linking with wysiwyg editors.'
package: User interface
core_version_requirement: ^8.8 || ^9
configure: entity.linkit_profile.collection
test_dependencies:
  - imce:imce

no "version" key. I installed it with composer.

So this means, it can't compare versions, and the you get a compatibility error.

Steps to reproduce.

• Install linkit 5 dev version (so there's no version key from packing script in the info file) and linkit_media_library with composer.
• Since linkit.info is missing version key, a requirements error appears, even though the correct version is installed.

Linkit (Version >=8.x-5.x required)
Linkit Media Library requires this module and version. Currently using Linkit version

I wrote one test, but I see this bug appears in two places /admin/modules and /admin/reports/status, and it turns out, the code is in two places, with the same bug, where if the version is missing in an info file (which I believe happens with dev versions of modules), it outputs a mangled error message.

If a dependency doesn't provide a version, then I think version requirement should not be enforced. The only times this should happen is 1) a project is hosted somewhere other than D.O. and simply doesn't declare a version and 2) a project that is Git cloned from D.O. In the first case, any requirement error is the fault of the requiring module. In the second case, there's no error. That's just a developer doing normal developer stuff.

In the case of *-dev versions, there's no easy way to determine if the dev release is new or older than the required version. Dev releases should be opted out, although we could check the major version (e.g. Module A requires >=8.x-5.x of Module B. 5.x-dev and 6.x-dev would pass, but 4.x-dev would not.)

Experienced a very similar issue here while trying a drush updb or update.php procedure.
(Message in spanish)

 [error]  Snippet Manager requiere este modulo y versión. Actualmente se esta utilizando The CodeMirror Editor version  (Currently using Dependencia no determinada The CodeMirror Editor (Se necesita la versión >= 8.x-1.4)) 

Notice the following lines are very recent and generated by script it seems:
Information added by Drupal.org packaging script on
in line 9

Looks like developer has missed declaring the version and this blocks updates.
It seems my local environment composer library repository is fetching the fresh one but in development environment is not.

Re #24, it sounds like you're working with code from the project's Git repo and not from a packaged version of the module. The module version is added to the info.yml file by the Drupal.org packaging script. That said, you're still in the right place!

This was a bugsmash random issue of the day and discussed with borisson_, dww, lendude, smustgrave, larowlan and myself.

The error message is no longer displayed because of #3239287: Fix \Drupal\Core\Extension\ModuleDependencyMessageTrait to not cause deprecations in PHP 8.1 which, when there is no version, sets the version to an empty string. When there is no version string the constraint is not checked, so no error message. That suggests this can be closed as outdated.

In order to have a module without a version property in the info.yml the module needs to be downloaded via git or use composer to get a dev version. Then if a dependent module requires a specific version, a check can not be made because the version string does not exist. The steps to reproduce in the Issue Summary needs to be updated to reflect that. Adding tag.

So, what to do here? borisson_ suggested that packaging script/composer facade could add a version. The dww chimed in, here is the quote from #bugsmash

This was never “supposed” to work. Either you used tarballs, or you had to use cvs_deploy if you wanted update status to work. That evolved into git_deploy and now there’s some composer-esque solution, too (maybe “composer_deploy”?).
All that said, it’d be nice if core more gracefully handled this case by printing a more precise & actionable error message. But I don’t think we should be trying to get core itself to solve this completely. (edited)

Based on that, closing this as outdated and opening a new issue, a task, to add a better error message for this case.

Moved credit to the new issue, #3300838: Add informative message when module does not have a version property