typo3fluid/fluid dependency picked up as sysext fluid #553
Comments
|
I think the main issue lies in |
|
Does your extension have a This is quite a hard topic, as "fallback" still needed. Some extensions do not have a 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 |
We're using functionalities from
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. |
|
@saitho Read the whole thread again.
The point here is, that Thus simply don't mention / drop the non TYPO3 extension from You may still keep it as require entry within your extension composer.json. Within the Can you test this again by droping the "invalid" package as test extension to load entry ? |
…Manager` The `ComposerPackageManager` has been introduced to streamline the functional test instance creation process and provide all selected extensions (system, custom and test fixture) within the test instance, which original simply used relative path names for classic mode instances or a simple extension key: For `$coreExtensionsToLoad`: * typo3/sysext/backend * backend For `$testExtensionsToLoad`: * typo3conf/ext/my_ext_key * my_ext_key With `typo3/cms-composer-installers` version 4.0RC1 and 5 these paths could not be found anymore, because TYPO3 system extensions and extensions are no longer installed into the classic paths in a composer mode instance and left in the vendor folder, which is the case for usual root project or extension instance. Using the available composer information to determine the source for extensions unrelated to the real installation path, which can be configured with composer, was the way to mitigate this issue and `ComposerPackageManger` has been implemented to process these lookups while still supporting test fixture extensions not loaded by the root composer.json directly. The implementation tried to provide backwards compatible as much as possible along with fallback to use folder names as extension keys by simply using `basename()` in some code places and including not obvious side effects and lookup issues. `basename()` was also used on valid composer package names to resolve composer package name for that value as extension key for loaded packages, which leads to fetch the wrong composer package. The standlone fluid `typo3fluid/fluid` composer package name resolved and retrieved the TYPO3 system extension package `typo3/cms-fluid` using `getPackageInfo()`, which lead to issues in other places, for example the dependency ordering and resolving class `PackageCollection`. This change streamlines the `ComposerPackageManager` class to mitigate building and using invalid values to lookup extension composer package names and harden the registration process of extension even further. Guarding unit tests are added to cover this bugfix. Resolves: #553 Releases: main, 8
…Manager` The `ComposerPackageManager` has been introduced to streamline the functional test instance creation process and provide all selected extensions (system, custom and test fixture) within the test instance, which original simply used relative path names for classic mode instances or a simple extension key: For `$coreExtensionsToLoad`: * typo3/sysext/backend * backend For `$testExtensionsToLoad`: * typo3conf/ext/my_ext_key * my_ext_key With `typo3/cms-composer-installers` version 4.0RC1 and 5 these paths could not be found anymore, because TYPO3 system extensions and extensions are no longer installed into the classic paths in a composer mode instance and left in the vendor folder, which is the case for usual root project or extension instance. Using the available composer information to determine the source for extensions unrelated to the real installation path, which can be configured with composer, was the way to mitigate this issue and `ComposerPackageManger` has been implemented to process these lookups while still supporting test fixture extensions not loaded by the root composer.json directly. The implementation tried to provide backwards compatible as much as possible along with fallback to use folder names as extension keys by simply using `basename()` in some code places and including not obvious side effects and lookup issues. `basename()` was also used on valid composer package names to resolve composer package name for that value as extension key for loaded packages, which leads to fetch the wrong composer package. The standlone fluid `typo3fluid/fluid` composer package name resolved and retrieved the TYPO3 system extension package `typo3/cms-fluid` using `getPackageInfo()`, which lead to issues in other places, for example the dependency ordering and resolving class `PackageCollection`. This change streamlines the `ComposerPackageManager` class to mitigate building and using invalid values to lookup extension composer package names and harden the registration process of extension even further. Guarding unit tests are added to cover this bugfix. Resolves: #553 Releases: main, 8
…Manager` The `ComposerPackageManager` has been introduced to streamline the functional test instance creation process and provide all selected extensions (system, custom and test fixture) within the test instance, which original simply used relative path names for classic mode instances or a simple extension key: For `$coreExtensionsToLoad`: * typo3/sysext/backend * backend For `$testExtensionsToLoad`: * typo3conf/ext/my_ext_key * my_ext_key With `typo3/cms-composer-installers` version 4.0RC1 and 5 these paths could not be found anymore, because TYPO3 system extensions and extensions are no longer installed into the classic paths in a composer mode instance and left in the vendor folder, which is the case for usual root project or extension instance. Using the available composer information to determine the source for extensions unrelated to the real installation path, which can be configured with composer, was the way to mitigate this issue and `ComposerPackageManger` has been implemented to process these lookups while still supporting test fixture extensions not loaded by the root composer.json directly. The implementation tried to provide backwards compatible as much as possible along with fallback to use folder names as extension keys by simply using `basename()` in some code places and including not obvious side effects and lookup issues. `basename()` was also used on valid composer package names to resolve composer package name for that value as extension key for loaded packages, which leads to fetch the wrong composer package. The standlone fluid `typo3fluid/fluid` composer package name resolved and retrieved the TYPO3 system extension package `typo3/cms-fluid` using `getPackageInfo()`, which lead to issues in other places, for example the dependency ordering and resolving class `PackageCollection`. This change streamlines the `ComposerPackageManager` class to mitigate building and using invalid values to lookup extension composer package names and harden the registration process of extension even further. Guarding unit tests are added to cover this bugfix. Resolves: #553 Releases: main, 8
…Manager` The `ComposerPackageManager` has been introduced to streamline the functional test instance creation process and provide all selected extensions (system, custom and test fixture) within the test instance, which original simply used relative path names for classic mode instances or a simple extension key: For `$coreExtensionsToLoad`: * typo3/sysext/backend * backend For `$testExtensionsToLoad`: * typo3conf/ext/my_ext_key * my_ext_key With `typo3/cms-composer-installers` version 4.0RC1 and 5 these paths could not be found anymore, because TYPO3 system extensions and extensions are no longer installed into the classic paths in a composer mode instance and left in the vendor folder, which is the case for usual root project or extension instance. Using the available composer information to determine the source for extensions unrelated to the real installation path, which can be configured with composer, was the way to mitigate this issue and `ComposerPackageManger` has been implemented to process these lookups while still supporting test fixture extensions not loaded by the root composer.json directly. The implementation tried to provide backwards compatible as much as possible along with fallback to use folder names as extension keys by simply using `basename()` in some code places and including not obvious side effects and lookup issues. `basename()` was also used on valid composer package names to resolve composer package name for that value as extension key for loaded packages, which leads to fetch the wrong composer package. The standlone fluid `typo3fluid/fluid` composer package name resolved and retrieved the TYPO3 system extension package `typo3/cms-fluid` using `getPackageInfo()`, which lead to issues in other places, for example the dependency ordering and resolving class `PackageCollection`. This change streamlines the `ComposerPackageManager` class to mitigate building and using invalid values to lookup extension composer package names and harden the registration process of extension even further. Guarding unit tests are added to cover this bugfix. Resolves: #553 Releases: main, 8
What are you trying to achieve?
In my functional test I want to load an extension with
typo3fluid/fluiddependency via$testExtensionsToLoad.What do you get instead?
Loading the extension
my_extensionvia$testExtensionsToLoadresults in the following error:How to reproduce the issue?
As above, load an extension with
typo3fluid/fluiddependency in the functional test's$testExtensionsToLoadAdditional information you would like to provide?
ComposerPackageManager::resolvePackageNamerunsbasename()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 evaluatingisComposerDependencyto true.Specify some data of the environment
The text was updated successfully, but these errors were encountered: