typo3fluid/fluid dependency picked up as sysext fluid

[saitho]

What are you trying to achieve?

In my functional test I want to load an extension with typo3fluid/fluid dependency via $testExtensionsToLoad.

What do you get instead?

Loading the extension my_extension via $testExtensionsToLoad results in the following error:

Package "my_extension" depends on package "typo3fluid/fluid" which does not exist.

How to reproduce the issue?

As above, load an extension with typo3fluid/fluid dependency in the functional test's $testExtensionsToLoad

Additional information you would like to provide?

ComposerPackageManager::resolvePackageName runs basename() on the vendor "typo3fluid/fluid", leaving "fluid" which is the extension key of sysext:fluid, therefore loading the PackageInfo of sysext:fluid (not that of typo3fluid/fluid) and incorrectly evaluating isComposerDependency to true.

Specify some data of the environment

• TYPO3 testing framework version: 8.0.9
• TYPO3 version: 12
• TYPO3 installation type: Composer
• PHP version: 8.1.27
• Web server used + version:
• Operating system: Ubuntu 20.04

[saitho]

I think the main issue lies in getPackageInfo with the argument $name being used with extension key (in which it needs to be resolved into the package name) and the package name (where it must not get resolved via resolvePackageName)

[sbuerk]

Does your extension have a ext_emconf.php in place ?

This is quite a hard topic, as "fallback" still needed. Some extensions do not have a ext_emconf.php anymore, but functional test instances a non-composer mode installations. Symlinking by name (special system extensions) is done by extension key. And on top, for test fixture extensions there are variants having ext_emconf.php but no composer.json, they way round and therefore "assumes" the folder name (basename) as extension key to full-full this in all directions.

That leads to naming conflicts.

What is the reason to have the "low-level" fluid packages as dependencie added ? Would it not be enough to add typo3/cms-fluid as dependency which itself depends on fluid ? At least as a workaround.

I will look into that, but this requires quite a lot of time with all moving parts - so it may take a while until I find enough time for this and re-arrange all parts.

Dealing with packages/extensions "replaceing" other extension becomes even harder, as these informations are not downloaded by composer and are not available :/.

Note: The fallback has been added to be compat with prior behaviour / pre-composer-installers 4RC1/5

[saitho]

What is the reason to have the "low-level" fluid packages as dependencie added ? Would it not be enough to add typo3/cms-fluid as dependency which itself depends on fluid ? At least as a workaround.

We're using functionalities from TYPO3Fluid\Fluid namespace in PHP, which is why we also add a typo3fluid/fluid to our extension's dependencies.

Some extensions do not have a ext_emconf.php anymore, but functional test instances a non-composer mode installations.

That's a great hint. We removed our ext_emconf.php files when we upgraded to TYPO3 12. Keeping this in mind, it may be a great help to get it working with the dependency in place. For now, we removed it.

[sbuerk]

@saitho Read the whole thread again.

In my functional test I want to load an extension with typo3fluid/fluid dependency via $testExtensionsToLoad.

The point here is, that $testExtensionsToLoad is only for TYPO3 extensions and not for any usual composer dependencies. Simply drop it. The core EXT:fluid is required anyway per default and the standalone fluid package, required by the TYPO3 core, loaded anyway and available within the functional test instance.

Thus simply don't mention / drop the non TYPO3 extension from $testExtensionsToLoad.

You may still keep it as require entry within your extension composer.json. Within the ext_emconf.php you may want to add fluid (TYPO3 system extension EXT:fluid) to emphasize this.

Can you test this again by droping the "invalid" package as test extension to load entry ?