10000 Dynamically fix compatibility with doctrine/data-fixtures v2 by greg0ire · Pull Request #58865 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

Dynamically fix compatibility with doctrine/data-fixtures v2 #58865

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Nov 20, 2024
Merged

Dynamically fix compatibility with doctrine/data-fixtures v2 #58865

merged 1 commit into from
Nov 20, 2024

Conversation

greg0ire
Copy link
Contributor
@greg0ire greg0ire commented Nov 13, 2024 •
edited
Loading
Q A
Branch? 5.4
Bug fix? yes
New feature? no
Deprecations? no
Issues see explanation below
License MIT

While working on allowing v2 of doctrine/data-fixtures in the bundle, I stumbled upon an issue that only affects some versions of Symfony that still have a ContainerAwareLoader class.

The signature of ContainerAwareLoader::addFixture() is not compatible with the v2 signature of the Loader interface from doctrine/data-fixtures, as per this fatal error:

Declaration of Symfony\Bridge\Doctrine\DataFixtures\ContainerAwareLoader::addFixture(Doctrine\Common\DataFixtures\FixtureInterface $fixture)
             must be compatible with Doctrine\Common\DataFixtures\Loader::addFixture(Doctrine\Common\DataFixtures\FixtureInterface $fixture): void

Classes that extend ContainerAwareLoader have to also extend Loader, meaning this is no breaking change because it can be argued that the incompatibility of the extending class would be with the Loader interface.

Closes #58861, Closes #58863

@carsonbot carsonbot added this to the 5.4 milestone Nov 13, 2024
@greg0ire greg0ire mentioned this pull request Nov 13, 2024
Closed
@greg0ire
Copy link
Contributor Author

How should I deal with the Psalm failures?

@derrabus
Copy link
Member

How should I deal with the Psalm failures?

Ignore them.

@greg0ire
Copy link
Contributor Author

Ignore them.

I'll assume you mean that literally because I couldn't find a baseline or psalm-suppress annotations to ignore them programmatically 😆

@greg0ire greg0ire mentioned this pull request Nov 13, 2024
Merged
@derrabus
Copy link
Member

Ignore them.

I'll assume you mean that literally

Yes. 😎

@greg0ire greg0ire force-pushed the fix-data-fixtures-v2-compat branch from fcfd7ac to f23ae10 Compare November 14, 2024 12:15
@chalasr
Copy link
Member
chalasr commented Nov 15, 2024

Not sure if the failing test is related?

@greg0ire
Copy link
Contributor Author

The Windows test? It's about http-foundation 🤔
Also, it fails on other PRs.

If you're talking about Psalm, the failure is definitely related, but I was told above to ignore it.

@chalasr
Copy link
Member
chalasr commented Nov 15, 2024

Sorry, I mean this one on the high-deps build: https://github.com/symfony/symfony/actions/runs/11836984636/job/32983037386?pr=58865.
That test seems to pass on current 5.4, can you please have a look?

@greg0ire
Copy link
Contributor Author
greg0ire commented Nov 15, 2024 •
edited
Loading

Oh right, that one does look like it could be related. I'll take a look.

I introduced the failing assert in doctrine/persistence 3.3.3: doctrine/persistence#375
Some passing builds allow a version higher than that though, that means there must be another explanation.

The object that does not pass the instanceof check is instanciated by a container that itself is created in a very fishy way. This line in particular is interesting:

symfony/src/Symfony/Bridge/Doctrine/Tests/ManagerRegistryTest.php

Line 30 in 75da5aa

$container->getDefinition('foo')->setLazy(true)->addTag('proxy', ['interface' => ObjectManager::class]);

I suspect the feature it leverages is not implemented when using the deps of the 8.2 job. I don't quite understand why it would break only now though. Maybe allowing doctrine/data-fixtures 2 resulted in slightly different deps?

@greg0ire
Copy link
Contributor Author

@MatTheCat maybe you can help with this?

@greg0ire
Copy link
Contributor Author

Just noticed the DI tag present in the line I mentioned is missing on 5.4 and was introduced in 6a4d229 , hence my last commit, which sadly doesn't seem very successful.

@greg0ire greg0ire force-pushed the fix-data-fixtures-v2-compat branch from 10ff8aa to 928bf70 Compare November 15, 2024 15:55
@greg0ire
Copy link
Contributor Author

Ah this might be what I need to backport: #57489

@MatTheCat
Copy link
Contributor

Err I don’t think I can help 😅 ; I recently committed to the DoctrineBridge but it doesn’t look like it was related.

@greg0ire
Copy link
Contributor Author

Yes, sorry!

@greg0ire greg0ire force-pushed the fix-data-fixtures-v2-compat branch from 928bf70 to 0abc40d Compare November 15, 2024 16:50
@greg0ire greg0ire force-pushed the fix-data-fixtures-v2-compat branch from f23ae10 to e20459a Compare November 15, 2024 16:55
@greg0ire
Copy link
Contributor Author

This only happens in high-deps mode, which apparently checks out 4.4, that's quite peculiar. At this point I don't really understand what's going on. @xabbuh maybe you would?

@xabbuh
Copy link
Member
xabbuh commented Nov 16, 2024

@greg0ire you can ignore the high deps failures

@greg0ire @nicolas-grekas
Dynamically fix compatibility with doctrine/data-fixtures v2
1812aaf 
Classes that extend ContainerAwareLoader have to also extend Loader, meaning
this is no breaking change because it can be argued that the incompatibility of
the extending class would be with the Loader interface.
@nicolas-grekas nicolas-grekas force-pushed the fix-data-fixtures-v2-compat branch from e20459a to 1812aaf Compare November 20, 2024 10:49
@nicolas-grekas
Copy link
Member

Thank you @greg0ire.

@nicolas-grekas nicolas-grekas merged commit c098762 into symfony:5.4 Nov 20, 2024
9 of 12 checks passed
@greg0ire greg0ire deleted the fix-data-fixtures-v2-compat branch November 20, 2024 13:09
This was referenced Nov 27, 2024
Merged
Merged
Closed
Merged
Merged
@greg0ire greg0ire mentioned this pull request Dec 11, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@derrabus derrabus derrabus approved these changes

@xabbuh xabbuh xabbuh approved these changes

@chalasr chalasr chalasr approved these changes

Assignees
No one assigned
Labels
Bug Status: Reviewed
Projects
None yet
Milestone
5.4
Development

Successfully merging this pull request may close these issues.
7 participants
@greg0ire @derrabus @chalasr @MatTheCat @xabbuh @nicolas-grekas @carsonbot
0