-
Notifications
You must be signed in to change notification settings - Fork 15
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.
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
Issue #41 - Fix skins installing into the wrong directory #42
Conversation
The vendor directory into which extensions get installed is set once and sub- sequently cached in the ExtensionInstaller class, from which both the Plugin- and the SkinInstaller classes inherit. This code used to work as intended, however PHP 8.1 changed the behaviour [1] and now all child classes share the static variable they inherited from their parent class. This means that when the plugin installer needs to install both regular plugins *and* skins within the same install session, the same path ends up being used both for skins and plugins, so one or the other ends up in the wrong directory. The fix for this is based on the proposed workaround contained in the respective PHP RFC at [1]. [1] https://wiki.php.net/rfc/static_variable_inheritance
Thinking about it – what is the minimum PHP version that the plugin installer still needs to support? If it's < 7.4, I guess I should throw out the null coalescing assignment operator again… (Edit: Just noticed that Roundcube 1.6 only requires 7.3, so I need to change that bit) |
afb0db2
to
74f8836
Compare
Thanks for raising this merge request! |
@thomascube, could you please check and merge? Thanks! |
@alecpl, @ChristophWurst, could you maybe take a look here? |
static $vendorDir; | ||
if ($vendorDir === null) { | ||
$vendorDir = $this->getVendorDir(); | ||
static $vendorDir = []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, $this->getVendorDir()
returns getcwd()
.
I belive we should use composer API instead and not cache the result at all (or cache it using all the variables that were used to parametrize the API).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently,
$this->getVendorDir()
returnsgetcwd()
.
In this class. But it's being overridden by both the PluginInstaller
and the SkinInstaller
subclasses, which do the actual work of plugin installation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is getcwd()
too which is fragile. It would be much better to query composer API where roundcube/roundcube
package is. Such result will be guaranteed to be "script runtime stable" and IMO fast enough to not need any caching.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on https://github.com/phpstan/extension-installer/blob/1.3.1/src/Plugin.php#L137 it should be easy as:
$composer = $event->getComposer();
$installationManager = $composer->getInstallationManager();
return $installationManager->getInstallPath('roundcube/roundcubemail');
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's roundcube/roundcubemail
and it does not exist if you didn't install Roundcube as a dependency. SO, that wouldn't work. Am I right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks to #44 this is always satisfied. Root-project (in sense of composer terminology, ie. installed as main project/not as dependency) can be analysed using composer API perfectly as well :).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mvorisek Thanks for the tip with the composer API, I will take a look.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will be fixed in #47. Can you please test/review?
I believe this is fixed with #47. Closing. |
Looks like it is even more broken than before:
|
What are the steps to reproduce? |
And what Composer version? |
Ok, I just reproduced it by calling @mvorisek could you check that? |
Also happens with other packages beside larry, I tested using the 1.6.6 docker images, so it's compose 2.6.6 here. |
@alecpl I somehow tested #47 wrongly and it should be fixed by #48. Also, in composer/composer#11927 I am checking if there is even a better solution, but for standard Roundcubemail installed as a root package, the #48 should be working. |
Seems to be working for me. |
Fixed in 0.3.5. ps. if you have plugins/skins installed you might need to remove them from composer.json to be able to update the plugin-installer. |
The vendor directory into which extensions get installed is set once and subsequently cached in the ExtensionInstaller class, from which both the Plugin- and the SkinInstaller classes inherit.
This code used to work as intended, however PHP 8.1 changed the behaviour [1] and now all child classes share the static variable they inherited from their parent class. This means that when the plugin installer needs to install both regular plugins and skins within the same install session, the same path ends up being used both for skins and plugins, so one or the other ends up in the wrong directory.
The fix for this is based on the proposed workaround contained in the respective PHP RFC at [1].
[1] https://wiki.php.net/rfc/static_variable_inheritance