search

liip / LiipTestFixturesBundle

This bundles enables efficient loading of Doctrine fixtures in functional test-cases for Symfony applications
https://liip.ch
MIT License
164 stars 45 forks source link

[Bug]: Undeclared dependency on doctrine/dbal ^3.1.0 | ^4.0.1 #276

Open Tetragramat opened 4 months ago

Tetragramat commented 4 months ago

Preconditions

I've been upgrading old project and I began suddenly getting errors

Error: Call to undefined method Doctrine\DBAL\Connection::createSchemaManager()

/home/www/_project_/vendor/liip/test-fixtures-bundle/src/Services/DatabaseTools/ORMDatabaseTool.php:182

Later I've found that newest liip/test-fixtures-bundle 2.7.3 does not work with my current doctrine/dbal 2.13.9 because liip/test-fixtures-bundle has, based on this commit https://github.com/doctrine/dbal/commit/79ee9d0fe4835a670eed2f519228c12e308854a2, undeclared dependency on doctrine/dbal ^3.1.0 | ^4.0.1

Steps to reproduce

Have project with liip/test-fixtures-bundle 2.7.3 and doctrine/dbal 2.13.9 and run tests.

Expected result

Composer should not allow me such combination even install. Alternatively liip/test-fixtures-bundle should throw exception that it needs specific version of doctrine/dbal.

Actual result

Error: Call to undefined method Doctrine\DBAL\Connection::createSchemaManager()

alexislefebvre commented 4 months ago

IIRC, these dependencies weren't required because the bundle can be loaded without these dependencies. Then people were expected to add the required dependencies when using the bundle: https://github.com/liip/LiipTestFixturesBundle/blob/2.x/doc/database.md

But the doc is unclear about the Composer dependencies and as you said the DX is not great.

So it would be better to require the dependencies directly.

Would you be able to open a PR to update the dependencies?

mbabker commented 4 months ago

You can use the conflict section for this. That's how a lot of packages (including Symfony itself) deals with restricting versions on optional dependencies.

There's already a conflict here for the DBAL for <2.11, so this implies that in theory any DBAL release from 2.11 up to present should be compatible. Based on this bug report, that's not the case right now. So there are two options:

1) Update the conflict to match the lowest supported version, which at this point probably should be a DBAL 3.x version (a lot of the ecosystem is now dropping support for DBAL 2, so it may no longer be worth the hassle to support it here) 2) Update the code to ensure compatibility with that minimum requirement

I would personally argue for the first option, as well as ensuring conflicts are configured for all optional dependencies. Looking at the latest merge to the 2.x branch, the PHP 7.4 build with the --prefer-lowest flag is installing these Doctrine packages:

Some of these are much more recent than the lowest versions in composer.json, which could be a combination of the resolver figuring things out or various upstream dependencies bumping their minimums which causes the minimums here to no longer be installable.

alexislefebvre commented 4 months ago

See: