Repository navigation
Conversation
Member
|
Thanks for the PR. However this introduces a bunch of edge cases that I am not super keen on having, so I'd rather first investigate the root cause (#13248 (comment)) before deciding on any further action. |
Author
|
Thanks for taking a look. Happy to leave this open while you dig into the initialization order — if you'd rather I close it until the root cause is clear, or rework it in a different direction once you know more, just say the word. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #13248
When a root package's dependencies are installed by a custom installer to a non-
vendor/location, the plugin runtime autoloader still recordsvendor/paths for them. Plugin commands then warn about classmap files that cannot be found, e.g.Could not scan for classes inside ".../vendor/roundcube/carddav/carddav.php"for a package that actually lives underplugins/.Root cause:
PluginManager::registerPackage()resolves the dependency install paths before the plugin is activated, so a custom installer provided by that very plugin is not registered yet. The lookup falls back toLibraryInstaller, which always derivesvendor/<name>. The main autoloader is not affected because it runs after plugin activation.This change uses the path Composer already records at install time:
FilesystemRepositoryretains each package's recordedinstall-pathfrominstalled.jsonon load, with a newgetInstallPath()that resolves it against the repository file's directory.PluginManager::getInstallPath()prefers the recorded path (local and global repositories) and falls back to the previous derivation otherwise, so in-memory repositories, metapackages and mid-install registrations behave exactly as before.Tests: a new
PluginManagerTestregression test with custom-installer fixtures fails on current main with the reporter's exact warnings and passes with this change. I also reproduced the Roundcube-style setup end to end offline: the warnings appear on main and are gone with the fix. The full test suite shows the same failures before and after this change (pre-existing environment issues, e.g. missing ext-intl).