Your requirements could not be resolved to an installable set of packages. (5.3.12)

[Aspyryan]

When trying to install this package using composer require thecodingmachine/tdbm 5.3.12 -W or with 5.* or without -W option, the install fails with this message Your requirements could not be resolved to an installable set of packages. How do I figure out what exactly is going on and what needs an update...

Full error: (Click)

``` ./composer.json has been updated Running composer update thecodingmachine/tdbm Loading composer repositories with package information Updating dependencies Your requirements could not be resolved to an installable set of packages. Problem 1 - mouf/utils.log.psr.multi-logger[v1.0.0, ..., 1.0.x-dev] require psr/log ~1.0 -> found psr/log[1.0.0, ..., 1.1.4] but the package is fixed to 3.0.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command. - thecodingmachine/tdbm v5.3.12 requires mouf/utils.log.psr.multi-logger ^1.0 -> satisfiable by mouf/utils.log.psr.multi-logger[v1.0.0, 1.0.x-dev]. - Root composer.json requires thecodingmachine/tdbm 5.3.12 -> satisfiable by thecodingmachine/tdbm[v5.3.12]. Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions. Installation failed, reverting ./composer.json and ./composer.lock to their original content. ```

composer.json: (Click)

```json { "require-dev": { "samdark/sitemap": "^2.4" }, "require": { "rbdwllr/reallysimplejwt": "^5.0", "google/recaptcha": "1.3", "slim/slim": "4.*", "slim/psr7": "^1.6", "php-di/php-di": "^7.0", "phpoffice/phpword": "^1.2", "phpmailer/phpmailer": "^6.8", "google/apiclient": "2.15.0", "brick/json-mapper": "^0.1.1", "catfan/medoo": "^2.1", "monolog/monolog": "^3.5" }, "autoload": { "psr-4": { "xxx\\": "www/admin", "xxx\\calendar\\": "calendar", "xxx\\common\\": "common" }, "files": [ "www/admin/api/mappers/mapLid.php" ] }, "minimum-stability": "dev", "prefer-stable": true } ```

[homersimpsons]

Hello, looks like composer cannot resolve psr/log to ~1.0 because it is already required as 3.0.0. Can you check the output of composer why psr/log? Also it may be possible to downgrade psr/log to ~1.0.

[Aspyryan]

dir>composer why psr/log
monolog/monolog 3.5.0  requires psr/log (^2.0 || ^3.0)
slim/slim       4.12.0 requires psr/log (^1.1 || ^2.0 || ^3.0)

Is there any reason why this package does not support higher then 1.0? Just asking cuz I don't really know the workings of php packages and stuff

[homersimpsons]

monolog/monolog 3.5.0 requires psr/log (^2.0 || ^3.0)

Okay so this is because of monolog/monolog.

Is there any reason why this package does not support higher then 1.0?

Technically speaking this is the mouf/utils.log.psr.multi-logger package that does not support latest psr/log versions. I think it should be able to support those versions, no one took time to upgrade support and adapt the code yet.

It seems that changes are just regarding typing https://github.com/php-fig/log/releases

[homersimpsons]

@Aspyryan this should work with https://github.com/thecodingmachine/utils.log.psr.multi-logger/releases/tag/v1.1.0 can you try again?

[Aspyryan]

@homersimpsons you are actually insane! Thank you so much, will have a look

[Aspyryan]

Alright @homersimpsons, was able to get it working thanks to you! I did have to enable 'intl' extention and I had to add:

  "minimum-stability": "dev",
  "prefer-stable": true

because of:

thecodingmachine/tdbm v5.3.12 requires brain-diminished/schema-version-control dev-master -> found brain-diminished/schema-version-control[dev-master] but it does not match your minimum-stability.

Would it be possible to use a release version of this package for tdbm? I saw there were no releases but maybe thecodingmachine could fork 1 and release themselves?

[homersimpsons]

Would it be possible to use a release version of this package for tdbm? I saw there were no releases but maybe thecodingmachine could fork 1 and release themselves?

Sadly this package is not under our org and the developer is no longer a software engineer. We could create a fork for this but don't intend to for the forseeable future.

Actually latest tag 1.0.5 is up-to-date with latest master https://github.com/brain-diminished/schema-version-control/compare/1.0.5...master

So it should be possible to depends on the published release instead of the dev-master

[homersimpsons]

@Aspyryan this should be solved with https://github.com/thecodingmachine/tdbm/releases/tag/v5.3.13