-
Notifications
You must be signed in to change notification settings - Fork 17
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
Comments
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 |
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. |
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? |
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 |
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? |
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 |
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. |
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.
https://github.com/php-http/httplug#intro
Thoughts?
The text was updated successfully, but these errors were encountered: