Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 2: Drop PHP 7, update all libraries #28

Open
tacman opened this issue Mar 25, 2023 · 7 comments
Open

Version 2: Drop PHP 7, update all libraries #28

tacman opened this issue Mar 25, 2023 · 7 comments

Comments

@tacman
Copy link

tacman commented Mar 25, 2023

Since PHP 7 is past EOL, how about dropping it altogether?

Symfony 6 requires PHP 8, it'll just make going forward easier to not continue to support outdated tools.

We can use rector to refactor, and update the underlying libraries. We should drop http-plug, and use PSR-18 directly.

New client implementations and consumers should use the PSR-18 interfaces directly. In the long term, we expect PSR-18 to completely replace the need for HTTPlug.

https://github.com/php-http/httplug#intro

Thoughts?

@welcoMattic
Copy link
Member

welcoMattic commented Mar 25, 2023

The plan for this collection of packages (under php-translation) is to lead a transition to Symfony Translation Providers.

However, as some features in the bundle are not in the Symfony Translation package, we could keep thèse feature here in a new major version (like Profiler panel to add translation via UI, or Content Editable features).

For the specific case of the PHP-translation/translator package, I'm ok to upgrade it to a up to date stack 👍 feel free to contribute some PR

@tacman
Copy link
Author

tacman commented Sep 18, 2023

With Symfony 7 coming up, I thought I'd revive this issue, in particular what best practices we could use for a new version.

Dropping httpplug seems like a step in the right direction.

It's probably not essential, maybe just documenting some http clients is enough. I need the Symfony HttpClient (which already integrates with the profiler).

Really what I want is to be able to cache the translation calls, since they're slow and in some cases expensive. I'm not sure where that cache should be, though -- in this library, or in a Symfony bundle, or even the application level.

@tacman
Copy link
Author

tacman commented Jan 22, 2025

I think we want installation instructions along the lines of

composer install composer require php-translation/translator symfony/http-client nyholm/psr7
or 
composer require php-translation/translator guzzlehttp/guzzle http-interop/http-factory-guzzle:^1.0

That is, a bring-your-own-client. Alas, I've never quite figured out how to do this, and in my own code I just hard-code a Symfony client.

Beyond that, the code would benefit from upgrading to PHP 8 and taking advantage of the goodness that it offers.

I looked at adding libretranslate and deepl, but couldn't even install this without downgrading psr/log.

composer require php-translation/translator
./composer.json has been updated
Running composer update php-translation/translator
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires php-translation/translator * -> satisfiable by php-translation/translator[0.1.0, 0.1.1, 0.1.2, 0.1.3, 1.0.0, 1.1.0, 1.2.0].
    - php-translation/translator[0.1.0, ..., 0.1.3, 1.0.0] require php ^5.5 || ^7.0 -> your php version (8.3.15) does not satisfy that requirement.
    - php-translation/translator 1.1.0 requires php ^5.6 || ^7.0 -> your php version (8.3.15) does not satisfy that requirement.
    - php-translation/translator 1.2.0 requires psr/log ~1.0 -> found psr/log[1.0.0, ..., 1.1.4] but the package is fixed to 3.0.2 (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.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
You can also try re-running composer require with an explicit version constraint, e.g. "composer require php-translation/translator:*" to figure out if any version is installable, or "composer require php-translation/translator:^2.1" if you know which you need.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.
~/g/sites/dummy$ 

What are your thoughts on a new version that drops unsupported dependencies?

@bocharsky-bw
Copy link
Member

I think the code base hasn't been updated for a while, so pushing things up sounds good to me in general. What deps in specific you're talking about? Feel free to send a PR to discuss it

@tacman
Copy link
Author

tacman commented Jan 24, 2025

I have a branch with PHP 8.3+, but I just submitted a PR that would at least allow this to be installed with psr/log:^3, Right now, you can't install this package if you started with symfony new --webapp.

There are several PHP 8.4 warnings. Should those be fixed in the 1.0 version? Or bump to 2.0-dev and drop unsupported packages?

@bocharsky-bw
Copy link
Member

Sorry for the long reply! Thanks, I left some comments on those PRs. Warnings can be fixed later if the bundle still works on PHP 8.4, not a big deal I think.

IMO for version 2.0 we need some BC breaks. If we don't have any BC breaks here, we can just bump a minor release version - that would be enough, let's see the changeset first

@tacman
Copy link
Author

tacman commented Jan 29, 2025

Can you or @Nyholm review the http client integration? That part seems potentially the biggest change in a potential new version, since I think some of the underlying dependencies are no longer recommended.

Of course, I'd love to see symfony contracts used instead. Alas, beyond my skill set to know the right way to integrate it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants