laminas / laminas-cache

Caching implementation with a variety of storage options, as well as codified caching strategies for callbacks, classes, and output
https://docs.laminas.dev/laminas-cache/
BSD 3-Clause "New" or "Revised" License
101 stars 52 forks source link

Tag last version that used laminas-servicemanager v3 #301

Closed holtkamp closed 6 months ago

holtkamp commented 6 months ago

Feature Request

Allow use of PHP 8.3, laminas-cache and laminas-i18n.

Q A
New Feature no
RFC no
BC Break no

Summary

  1. To allow use of PHP 8.3 (and new psr-log) the use of the laminas-cache 4.0.x-dev branch is required, we used this in production for some time and it works without problems
  2. As of https://github.com/laminas/laminas-cache/commit/c21c57f2d1169f62fe5a932c4675323094c12cf1, laminas-servicemanager v4 is supported
  3. The last commit in this branch that used laminas-servicemanager v3 is https://github.com/laminas/laminas-cache/commit/3eaa2c0f1eb8f49e99ebb8beded803249292830b
  4. laminas-i18n requires laminas-servicemanager v3

So to be able to use PHP 8.3, laminas-cache and laminas-i18n we must force the use laminas-ache to https://github.com/laminas/laminas-cache/commit/3eaa2c0f1eb8f49e99ebb8beded803249292830b using "laminas/laminas-cache": "4.0.x-dev#3eaa2c0f1eb8f49e99ebb8beded803249292830b" in composer.json.

However, that seems not to work (used Composer 2.7.6), for example:

{
    "require": {
    "php": "~8.3.0",
    "laminas/laminas-cache": "4.0.x-dev#3eaa2c0",
        "laminas/laminas-i18n": "^2.26"
    }
}

or with complete SHA

{
    "require": {
    "php": "~8.3.0",
    "laminas/laminas-cache": "4.0.x-dev#3eaa2c0f1eb8f49e99ebb8beded803249292830b",
        "laminas/laminas-i18n": "^2.26"
    }
}

Results in:

Problem 1
    - laminas/laminas-servicemanager 3.21.0 requires php ~8.1.0 || ~8.2.0 -> your php version (8.3.6) does not satisfy that requirement.
    - Root composer.json requires laminas/laminas-cache 4.0.x-dev#3eaa2c -> satisfiable by laminas/laminas-cache[4.0.x-dev].
    - You can only install one version of a package, so only one of these can be installed: laminas/laminas-servicemanager[3.21.0, 3.22.0, 3.22.1, 4.1.0].
    - laminas/laminas-i18n 2.26.0 requires laminas/laminas-servicemanager ^3.21.0 -> satisfiable by laminas/laminas-servicemanager[3.21.0, 3.22.0, 3.22.1].
    - laminas/laminas-cache 4.0.x-dev requires laminas/laminas-servicemanager ^4.1 -> satisfiable by laminas/laminas-servicemanager[4.1.0].
    - Root composer.json requires laminas/laminas-i18n ^2.26 -> satisfiable by laminas/laminas-i18n[2.26.0].

The documentation https://getcomposer.org/doc/04-schema.md#package-links might suggest that the use of explicit references/commits has some limitations and might not work:

Note: This feature has severe technical limitations, as the composer.json metadata will still be read from the branch name you specify before the hash. You should therefore only use this as a temporary solution during development to remediate transient issues, until you can switch to tagged releases. The Composer team does not actively support this feature and will not accept bug reports related to it.

Is there any other way to realize this? Would it be an idea to tag https://github.com/laminas/laminas-cache/commit/3eaa2c0f1eb8f49e99ebb8beded803249292830b with 4.0.0-alpha or something?

PS: the strange thing, up until last week depending in "laminas/laminas-cache": "4.0.x-dev" worked without a problem... Reverting to a lower version of Composer did not help like 2.6.0 or 2.5.0 did not help.

UPDATE Experimented a bit more and this seems to be a viable workaround:

{
  "require": {
    "php": "~8.3.0",
    "laminas/laminas-cache": "4.0.0-alpha",
    "laminas/laminas-i18n": "^2.26"
  },
  "repositories": [
    {
      "type": "package",
      "package": {
        "name": "laminas/laminas-cache",
        "version": "v4.0.0-alpha",
        "source": {
          "url": "https://github.com/laminas/laminas-cache",
          "type": "git",
          "reference": "3eaa2c0f1eb8f49e99ebb8beded803249292830b"
        },
        "autoload": {
          "psr-4": {
            "Laminas\\Cache\\": "src/"
          }
        }
      }
    }
  ]
}
boesing commented 6 months ago

I am not sure if I understand the issue. There is https://github.com/laminas/laminas-cache/releases/tag/3.12.0 which supports PHP 8.3, laminas-i18n is not required by laminas-cache and thus there should be no limitation.

laminas-i18n has https://github.com/laminas/laminas-i18n/releases/tag/2.24.0 which supports PHP 8.3, so having laminas-cache 3.12.0+ with laminas-i18n 2.24+ should have full 8.3 support?

Neither cache nor i18n depend on psr/log so I am a bit lost here.

Can you provide a bit more details of the composer output which leads to the issue as I do not understand the dependency chain by reading the issue description.

Oh and laminas-servicemanager has https://github.com/laminas/laminas-servicemanager/releases/tag/3.22.0 which supports PHP 8.3 but whyever, your composer does require 3.21.0.

boesing commented 6 months ago

I quickly setup a test project and this is what I get:

composer require php:~8.3.0 laminas/laminas-cache:^3.12 laminas/laminas-i18n:^2.24 psr/log laminas/laminas-cache-storage-adapter-blackhole
./composer.json has been created
Running composer update php laminas/laminas-cache laminas/laminas-i18n psr/log laminas/laminas-cache-storage-adapter-blackhole
Loading composer repositories with package information
Updating dependencies
Lock file operations: 12 installs, 0 updates, 0 removals
  - Locking laminas/laminas-cache (3.12.1)
  - Locking laminas/laminas-cache-storage-adapter-blackhole (2.4.0)
  - Locking laminas/laminas-eventmanager (3.13.0)
  - Locking laminas/laminas-i18n (2.26.0)
  - Locking laminas/laminas-servicemanager (3.22.1)
  - Locking laminas/laminas-stdlib (3.19.0)
  - Locking psr/cache (1.0.1)
  - Locking psr/clock (1.0.0)
  - Locking psr/container (1.1.2)
  - Locking psr/log (3.0.0)
  - Locking psr/simple-cache (1.0.1)
  - Locking webmozart/assert (1.11.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 12 installs, 0 updates, 0 removals
  - Downloading webmozart/assert (1.11.0)
  - Downloading psr/simple-cache (1.0.1)
  - Downloading psr/clock (1.0.0)
  - Downloading psr/cache (1.0.1)
  - Downloading psr/container (1.1.2)
  - Downloading laminas/laminas-servicemanager (3.22.1)
  - Downloading laminas/laminas-eventmanager (3.13.0)
  - Downloading laminas/laminas-cache-storage-adapter-blackhole (2.4.0)
  - Downloading laminas/laminas-cache (3.12.1)
  - Downloading laminas/laminas-i18n (2.26.0)
  - Downloading psr/log (3.0.0)
  - Installing webmozart/assert (1.11.0): Extracting archive
  - Installing psr/simple-cache (1.0.1): Extracting archive
  - Installing psr/clock (1.0.0): Extracting archive
  - Installing psr/cache (1.0.1): Extracting archive
  - Installing laminas/laminas-stdlib (3.19.0): Extracting archive
  - Installing psr/container (1.1.2): Extracting archive
  - Installing laminas/laminas-servicemanager (3.22.1): Extracting archive
  - Installing laminas/laminas-eventmanager (3.13.0): Extracting archive
  - Installing laminas/laminas-cache-storage-adapter-blackhole (2.4.0): Extracting archive
  - Installing laminas/laminas-cache (3.12.1): Extracting archive
  - Installing laminas/laminas-i18n (2.26.0): Extracting archive
  - Installing psr/log (3.0.0): Extracting archive
15 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating autoload files
6 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
No security vulnerability advisories found.
Using version ^3.0 for psr/log
Using version ^2.4 for laminas/laminas-cache-storage-adapter-blackhole
→ php --version && composer check-platform-reqs
PHP 8.3.6 (cli) (built: Apr 10 2024 14:21:20) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.6, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.6, Copyright (c), by Zend Technologies
Checking platform requirements for packages in the vendor dir
ext-ctype 8.3.6   success 
ext-intl  8.3.6   success 
php       8.3.6   success 

So whatever is holding back servicemanager 3.22 should be outlined, you could try checking what is holding back by running:

composer why-not laminas/laminas-servicemanager 3.22
holtkamp commented 6 months ago

@boesing thanks a lot for the swift and detailed response!

I thought I prepared the issue thoroughly, but apparently I made a mistake: instead of psr/log I meant psr/cache. To allow using psr/cache 2.0|3.0 in a project, laminas-cache v4 is required and we started using laminas-cache 4.0.x-dev which worked properly until recently.

Hopefully this clarifies the issue report...

froschdesign commented 6 months ago

@holtkamp If I have understood the problem correctly, then this works:

Allow use of PHP 8.3, laminas-cache and laminas-i18n.

But not this:

  1. To allow use of PHP 8.3 (psr/cache 2.0|3.0)

Because:

4. laminas-i18n requires laminas-servicemanager v3

But this was expected and therefore any help is welcome to solve this.

holtkamp commented 6 months ago

@froschdesign thanks for the response.

My suggestion was only to tag some kind of "alpha pre-release" with the last commit to laminas-cache 4.0.x-dev which still supports laminas-servicemanager v3 in order to allow people to refer to it while development is done on the other laminas packages to gradually support laminas-servicemanager v4.

I can understand when this suggestion is declined, but it might help others out to already adopt laminas-cache 4.0 in combination with other laminas packages?

boesing commented 6 months ago

I will prepare laminas-cache v4 later this month but there is no cache adapter yet available which will support that version. So that wont help in your specific case. So you wont be able to use psr/cache v2+ at least for a couple of more weeks.

boesing commented 6 months ago

I'll close here as I think this is a duplicate of #292

holtkamp commented 6 months ago

I will prepare laminas-cache v4 later this month

Thanks, but that tagged version probably requires laminas-servicemanager v4, while my suggestion was to tag a version which still works with laminas-sevicemanager v3

but there is no cache adapter yet available which will support that version.

Not a problem since in some cases no adapter is even required, also see: https://github.com/laminas/laminas-cache/issues/192

Anyhow, I understand my situation might be a bit exotic and I found a workaround, thanks for the responses!