Incompatible HTTP factory

[jelleroorda]

Laravel Printing Version

3.0.3

Laravel Version

10.17.1

Print Driver

CUPS

Bug description

I've installed the package and the CUPS driver like documented. After setting up the credentials I try to show the available printers. This then results in an error.

So first:

composer require rawilk/laravel-printing
composer require smalot/cups-ipp

Then run tinker: php artisan tinker

Psy Shell v0.11.20 (PHP 8.1.3 — cli) by Justin Hileman
> dump(Printing::printers())

   LogicException  You cannot use "Http\Message\MessageFactory\GuzzleMessageFactory" as the "php-http/message-factory" package is not installed. Try running "composer require php-http/message-factory". Note that this package is deprecated, use "psr/http-factory" instead.                                                                                                                     

Basically we need the deprecated php-http/message-factory package to send requests.

However, when you install the deprecated package you get conflicts in the interfaces with the already currently installed psr/http-factory package:

composer require php-http/message-factory

Then run tinker: php artisan tinker

Psy Shell v0.11.20 (PHP 8.1.3 — cli) by Justin Hileman
> dump(Printing::printers())

In Stream.php line 79:
                                                                                                                             
  Declaration of Http\Client\Socket\Stream::close() must be compatible with Psr\Http\Message\StreamInterface::close(): void  

I suppose that we'd need to use the newly provided interfaces by psr/http-factory to fix the issue.

I can't drop the psr/http-factory package since it's being used by phpoffice/phpspreadsheet:

$ composer why psr/http-factory
guzzlehttp/psr7          2.6.0  requires psr/http-factory (^1.0) 
nyholm/psr7              1.8.0  requires psr/http-factory (^1.0) 
php-http/client-common   2.7.0  requires psr/http-factory (^1.0) 
phpoffice/phpspreadsheet 1.29.0 requires psr/http-factory (^1.0) 

Steps to reproduce

No response

Relevant log output

No response

[jelleroorda]

After researching, I've worked around it by installing the legacy interface, as well as locking psr/http-message to 1.*:

In the composer.json:

"psr/http-message": "1.*",

[ok200paul]

Thanks for this @jelleroorda - trying to overcome this issue myself. I'm still seeing this issue after popping the following into our composer.json and updating:

"psr/http-message": "1.*",

Could you please elaborate on what you mean by "installing the legacy interface"? Doe you mean installing "php-http/message-factory" here, alongside psr/http-message?

Thanks again for raising this issue, hopefully I can assist with a PR of some kind

[ok200paul]

Ah - found out what it was. I added the following to composer.json:

        "php-http/message-factory": "^1.1",
        "psr/http-message": "1.*",

.. and my printing began to work again.

I'll mount the package and see if I can get its dependencies updated into a PR so that we don't need to perform this legacy package fiddling 👍

[jelleroorda]

Yes, so basically I now have both installed, as well as pinned the psr/http-message to 1.* like you have. I've also had a quick look, but it looks like it will be quite some work to fix this issue, mostly because the smalot/cups-ipp package is 6 years old and basically deprecated. We should probably upgrade that one first, to use the current modern client.

[github-actions]

This issue is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[jelleroorda]

@rawilk Perhaps it’s an idea to remove this stale bot? You don’t seem to actively maintain this package currently (which is okay!).

Closing all these “actual issues” through the bot makes it seem like this package is actively maintained (keeps the issue count low). This is not very helpful for people who find this package and don’t immediately see this package is not actively maintained. It also has the effect that the same issue gets opened multiple times, because you’re unlikely to search for closed issues when you encounter an issue. For example, this issue is related to #70 which is found after opening this issue.

[rawilk]

@jelleroorda I can definitely remove the stale bot - seemed like a good idea at the time to add it.
I do maintain the package still, just not as frequently as I'd like to. I have email notifications turned off unless someone tags me, so I often forget to check all of my open source packages for new issues and PR's.

[rawilk]

I mentioned on #81 that I would like to just write my own implementation for CUPS at some point so we could just eliminate the smalot/cups-ipp dependency completely, since they haven't updated their PSR implementation for some time. Since I don't use CUPS myself, I don't really have any real incentive besides making my automated tests run easier for the package, so I don't know when or if I'll get a chance to do that. If anyone is able to come up with a good solution in the meantime, I'd definitely appreciate PR's on this.

[DmNick]

@rawilk josh-gaby/cups-ipp fixed smalot's repo and its working well

[rawilk]

@DmNick Thanks for the info. I'll look into it when I get a chance.