-
Notifications
You must be signed in to change notification settings - Fork 83
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
Update bundle for Sylius 1.9 / Symfony 4.4+||5.2+ #251
Conversation
…r with EntityManagerInterface to update bundle for sylius 1.9
Update bundle to make it work with Sylius 1.9
fixed returns
use FriendsOfSylius\SyliusImportExportPlugin\Exception\ImporterException; | ||
use FriendsOfSylius\SyliusImportExportPlugin\Processor\ResourceProcessorInterface; | ||
|
||
final class JsonResourceImporter extends ResourceImporter implements SingleDataArrayImporterInterface | ||
{ | ||
public function __construct( | ||
ObjectManager $objectManager, | ||
EntityManagerInterface $objectManager, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why was this change needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ie. why the switch to the ORM specific interface
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was encountering an error in both importers when trying to run any export/import commands, something of the sort
Fatal Error:
Argument 1 passed to XXX must be an instance of Doctrine\Common\Persistence\ObjectManager, instance of ContainerNrPkzm2\EntityManager_9a5be93 given
The short version is that to circumvent this, I changed these two typehints to reflect the object that was being injected 😄
The long version: I scratched my head at this for a while as
- ObjectManager is an interface
- EntityManagerInterface itself extends ObjectManager
But there seemed to be shenanigans I did not understand with what is being injected.ContainerNrPkzm2\EntityManager_9a5be93
itself seems to implement the wrong thing.
Some source: https://stackoverflow.com/a/45678423/2926899
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you have a look at what class_implements
returns?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can do 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should be able to typehint Doctrine\Persistence\ObjectManager
, I don't think I've ever seen the deprecation notice before where it specifically calls out to use the ORM's interface TBH. But, I did just monkey patch an app I'm trying to finish upgrading to Sylius 1.9 with the persistence namespace change and had zero issue using the base ObjectManager
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this remains the only concern I have left over merging this PR .. I have reached out to the Symfony community for advice once more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we have a test case that fails if we revert this change? if not, could we add one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
“ You’re using the persistence interface to autowire the entity manager. In future versions of DoctrineBundle (next major release) you’ll have to either alias this yourself or, better yet, inject the manager registry”
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I followed the advice you guys gave and reverted the typing and tested the import command and everything worked fine. I still think there is something there: both https://github.com/doctrine/DoctrineBundle/blob/2.2.x/UPGRADE-2.0.md#service-aliases and the fact that I did encounter the error from the original comment is strange 🤔
It would be great if someone else could give the import command a try and confirm that it does indeed work just fine with the ObjectManager typing 🙏
tl;dr it works just fine with the ObjectManager typing, as @mbabker implied 👍
thank you! do you also have time to look into the travis setup? |
No problem 👍 I can take a look at the travis setup too, I will update this PR once it's done ! |
BTW most OSS projects have migrated to GithubActions due to Travis slowness. but then again maybe due to everyone having moved Travis is now acceptable in speed. |
Ok, this first attempt with Travis did not go too well. I'm not super familiar with it but I'll attempt to run the pipeline locally if possible to tinker with it till it runs. 👍 |
I could imagine using composer 2 could solve the memory issue |
…k to ObjectManager typing in two services
…d up dependencies to ^4.4||^5.2
Composer updates
sylius-labs/coding-standard update
additional bundle updates
I made some progress on having a passing travis job 🙏 However, the builds are still failing. There is something obvious I must be missing. Locally I've had no issues with the composer update and everything is working fine, but the Travis job keeps failing on different dependencies mismatches. Here's what I run locally to simulate the job's steps: composer require "sylius/sylius:1.9.*" --no-update
composer config extra.symfony.require "^5.2"
composer update --prefer-dist And it goes through without hiccups. Not the case in the Travis job though. So I'll be using my fork for now, but I'll come back to this Travis job during the week. If anyone wants to give it a go, feel free ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @Gogopex for this PR :)
Travis is indeed in perpetual error, it's annoying.
To switch to Github Action, you can get inspiration from the PluginSkeleton file
https://github.com/Sylius/PluginSkeleton/blob/1.8/.github/workflows/build.yml
If you don't have time to do it, say it and I will try to do it quickly to validate your PR because she is important 🚀
Thank you, @oallain ! I decided to give up on fighting with Travis and started exactly what you are suggesting this morning: https://github.com/MyLittleParis/SyliusImportExportPlugin/pull/6/files Work got in the way but once I get the github action working on the fork, I will include it in this PR ! I do have one question: what do you think about dropping the support for Sylius <1.7 in order to reduce the number of builds that would run? Edit: github actions are currently down..! https://www.githubstatus.com/ |
So cool 😎
Yes, to drop Sylius 1.7 and less. But keep 1.8 version.
🤕 |
agreed for the bump to 1.8 .. and oh the irony of life with GA being down. but super appreciative of your commitment and work here @Gogopex |
* github action PoC from sylius invoicing plugin * Legacy build to build * dependencies updates * update build * update matrix dependency exclusion rules * forgot ^4.2 version of Symfony * legacy_build no longer relevant * removed travis.yml, updated composer.json * dropped 1.7 support * add workflow dispatch to be able to manually trigger the job * update github action * matrix order * ga fix * removed useless gulp steps * PluginSkeleton 1.9 pipeline * updated tests/Application based on SyliusSkeletonPlugin * action fix * fix * updated phpstan.neon * fix phpstan step * version bump + vendor change * version changes
Hi guys ! I've finally gotten around to finishing this up, here's what's new:
The pipeline is now fully working; however it now crashes on the Phpstan's step, which doesn't seem to have anything to do with this PR 👍 @oallain @lsmith77 see https://github.com/FriendsOfSylius/SyliusImportExportPlugin/actions/runs/683847071 for where it fails There is two solutions ahead imo:
I'm not sure I can fix all of these issues this week, but I might be able to in the next 10 days, if you guys are too busy. 👍 |
I think we should disable PHPStan in this PR and then have a follow up PR addressing this topic. This PR and you have been burdened so much already without a merge. Will do a deeper review tomorrow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello @Gogopex ,
Yes, just comment the PHPStan step, we will correct it in a future PR.
You've done so much already, I think we can merge like this.
Thanks !
* github action PoC from sylius invoicing plugin * Legacy build to build * dependencies updates * update build * update matrix dependency exclusion rules * forgot ^4.2 version of Symfony * legacy_build no longer relevant * removed travis.yml, updated composer.json * dropped 1.7 support * add workflow dispatch to be able to manually trigger the job * update github action * matrix order * ga fix * removed useless gulp steps * PluginSkeleton 1.9 pipeline * updated tests/Application based on SyliusSkeletonPlugin * action fix * fix * updated phpstan.neon * fix phpstan step * version bump + vendor change * version changes * cleaning up pipeline for merge * comment out PHPStan and PHPSpec * missing TreeBuilder arg * disable behat tests too * root to getRootNode
Hello, I've taken into account @mbabker's suggestion, thanks 👍 Turns out I also had to comment out PHPSpec (link to example failed build) along with Behat (link to example failed build) for now, otherwise the builds would not pass (the equivalent builds were failing on Jenkins before this PR 😦). I agree a second PR to fix PHPStan and PHPSpec would be great, along with a PR for the Behat tests! Then everything would be all tidied up! |
* github action PoC from sylius invoicing plugin * Legacy build to build * dependencies updates * update build * update matrix dependency exclusion rules * forgot ^4.2 version of Symfony * legacy_build no longer relevant * removed travis.yml, updated composer.json * dropped 1.7 support * add workflow dispatch to be able to manually trigger the job * update github action * matrix order * ga fix * removed useless gulp steps * PluginSkeleton 1.9 pipeline * updated tests/Application based on SyliusSkeletonPlugin * action fix * fix * updated phpstan.neon * fix phpstan step * version bump + vendor change * version changes * cleaning up pipeline for merge * comment out PHPStan and PHPSpec * missing TreeBuilder arg * disable behat tests too * root to getRootNode * added back ObjectManager typing
amazing work! I have created follow up tickets for PHPStan and PHPSpec |
I was met with quite a few errors trying to install this plugin on a brand new Sylius 1.9 webapp. I decided to take some time to fix these, in case you guys want to update this bundle for Symfony 1.9
This PR includes a bunch of updates to a few files:
symfonystopwatch
version, allowing the bundle to install succesfully after beingcomposer require
'dsrc/DependencyInjection/Configuration.php
which ensures that it both works on Symf 5.2, but also maintains BC with 4.1 and olderreplaced theObjectMapper
typings withEntityManagerInterface
: int
typing andreturn 0;
to theexecute()
of all commands (required by Symf 4.4+. I did not usereturn Command::Success
to maximize BC.)sylius.class_metadata.product_image
inservices.yml
to symf4.4+ formatWith just these changes, the bundle installs and all features are working fine. 👍
Note: the builds fail because they are using the old dependencies:
They should pass once the depency versions are
"sylius/sylius:1.9.* symfony/symfony:5.2.*"
👍