Install via composer error with psr/simple-cache latest version

[Ahmed-Elrayes]

This is:

- [x] a bug report
- [ ] a feature request
- [ ] **not** a usage question (ask them on https://stackoverflow.com/questions/tagged/phpspreadsheet or https://gitter.im/PHPOffice/PhpSpreadsheet)

What is the expected behavior?

install via composer

What is the current behavior?

i'm using laravel 9 which comes with psr/simple-cache v3

Problem 1 - Root composer.json requires phpoffice/phpspreadsheet ^1.23 -> satisfiable by phpoffice/phpspreadsheet[1.23.0]. - phpoffice/phpspreadsheet 1.23.0 requires psr/simple-cache ^1.0 || ^2.0 -> found psr/simple-cache[1.0.0, 1.0.1, 2.0.0, 2.x-dev] 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.

i've seen this issue psr/simple-cache:3.0.0 #2703 but unfortunately i need it to be used on the current project i'm working on.

What are the steps to reproduce?

support psr/simple-cache version 3.0

Please provide a Minimal, Complete, and Verifiable example of code that exhibits the issue without relying on an external Excel file or a web server:

If this is an issue with reading a specific spreadsheet file, then it may be appropriate to provide a sample file that demonstrates the problem; but please keep it as small as possible, and sanitize any confidential information before uploading.

What features do you think are causing the issue

• [ ] Reader
• [ ] Writer
• [ ] Styles
• [ ] Data Validations
• [ ] Formula Calulations
• [ ] Charts
• [ ] AutoFilter
• [ ] Form Elements

Does an issue affect all spreadsheet file formats? If not, which formats are affected?

Which versions of PhpSpreadsheet and PHP are affected?

PHP8.0 and PhpSpreadsheet 1.23

[MarkBaker]

As noted in the discussions related to that issue:

Because of the use of mixed type in simple-cache 3.0, we can't match our implementation to the simple-cache 3.0 interface until we support only PHP8 and above. The only way we could work it would be to have two version-specific implementations, and a run-time identifier that chose which one to use.

At this point I'm reluctant at this point to add extra complexity (with multiple implementations of the Cell Cache) in PhpSpreadsheet as a "workround".

1.23.0 Version download stats from packagist (even ignoring the fractional percent that are using versions of PHP below our minimum of 7.3 until the release of 8.2 in November) show that half are still below the minimum PHP 8.0 required for simple-cache 3.0, so without breaking our LTS of PHP version EOL + 1 year, we would need to create multiple implementations with a version selector.

I might consider changing the LTS for the PhpSpreadsheet v2.0 release later this year to be only supported PHP versions, which would be a minimum of PHP 8.0 from November; but we would then need to maintain PhpSpreadsheet 1.x until November 2024, which is a lot longer maintaining two major versions than I would like.

[Ahmed-Elrayes]

i see, thanks a lot for your reply, as a work around i've downgraded the version of simple cache.

[manuelmtz1864]

Puedes explicar como solucionaste el problema. Estoy presentando el mismo problema. Se agradecería :)

[wxyClark]

Puedes explicar como solucionaste el problema. Estoy presentando el mismo problema. Se agradecería :) downgraded the version of simple cach： composer require psr/simple-cache ^2.0 composer require maatwebsite/excel

[gharlan]

Because of the use of mixed type in simple-cache 3.0, we can't match our implementation to the simple-cache 3.0 interface until we support only PHP8 and above.

It is possible via a hack:

    #[PHP8] public function get($key, $default = null): mixed /*
    public function get($key, $default = null) /* PHP<8 */
    {
        // ...
    }

With php 7 the first line is a comment and the second line is the function signature. With php 8 the first line is the function signature and the second line is a comment.

But I'm not sure I would really use that hack. ;) Probably it's better to wait until you raise the minimum PHP version.

[MarkBaker]

It is possible via a hack:

    #[PHP8] public function get($key, $default = null): mixed /*
    public function get($key, $default = null) /* PHP<8 */
    {
        // ...
    }

It's a neat trick, and I wasn't aware of it: I've written some hacky dark voodoo code over the years; but I've always done my best to ensure that it never sees the light of day, and certainly never included it in any release that code be used in a production environment.

[neopheus]

today more than half are on php 8 or higher

[MarkBaker]

today more than half are on php 8 or higher

So you're saying that I should break the LTS contract with 39% of users, and require simple-cache 3.0? Or are you requesting that I take on the extra maintenance overhead of supporting two incompatible versions?

[neopheus]

today more than half are on php 8 or higher

So you're saying that I should break the LTS contract with 39% of users, and require simple-cache 3.0? Or are you requesting that I take on the extra maintenance overhead of supporting two incompatible versions?

No. I say that php 8 is now in the majority. For the LTS version it is normal to modify nothing to keep compatible with php 7.4. But having a special version of php 8 and higher could be a good idea

[MarkBaker]

But having a special version of php 8 and higher could be a good idea

That might seem a nice simple answer, and it is for you as an end-user of this library, but it means that I need to maintain multiple major versions for at least the next 18 months.

I'm already struggling finding the time to get version 2.0 ready for release, which will give me two major versions to maintain in parallel, but 2.0 falls under the same LTS as version 1.x, so the timeline overlap for that would depend in how quickly library users updated to the 2.0 release. Having yet another major version for PHP8+ and requiring simple-cache 3.0 would mean I have to maintain three separate versions of the library