-
Notifications
You must be signed in to change notification settings - Fork 16
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
Major update v5.0 #25
Conversation
References: - ffraenz/private-composer-installer#25 Resolves junaidbhura#19
Hi @ffraenz I was working on upgrading junaidbhura/composer-wp-pro-plugins to support Composer v2 and this pull request was quite helpful to understand the internal changes made to Composer. I believe I've reached a similar roadblock to you, based on tests of both plugins: in Composer v2, all packages get downloaded first then prepared/installed/updated/uninstalled/cleaned-up. This means changing the package dist URL in I bring this up because I'm curious to see what other people have been planning to do about this predicament. I'm under the impression that any Composer plugin that dynamically alters a package's dist URL (and by extension the cache key) will need a custom I'm available to help out with this plugin. Thanks, /cc @junaidbhura |
Hi @mcaskill, indeed I hit a roadblock when I found out that the remote filesystem could no longer be exchanged in Composer 2 to replace the dist URL. I wrote to one of the Composer maintainers and worked out a set of changes to make an interface available to us. You can now simply call I still need to incorporate the changes into this repository to finalize v5. I'm always open to suggestions and/or contributions to this plugin, so feel free to join if you're up to it! |
I had not seen the that pull request at the time but I have implemented The roadblock I'm at is the cache key in |
References: - ffraenz/private-composer-installer#25 Resolves junaidbhura#19
As far as I know the caching strategy does not change much moving forward to Composer 2. In this project I make sure a version number is always included in the dist URL (and in |
References: - ffraenz/private-composer-installer#25 Resolves junaidbhura#19
Hi @ffraenz, I'm sorry, I have been poorly explaining the issue I'm encountering with both your package and the one I'm working on.
Yes, the caching strategy hasn't changed. What has changed is the processing strategy. Your unit tests are only testing what your plugin can do with a package. Example:1. PackageACME_KEY=foobar {
"type": "package",
"package": {
"name": "acme/anvil",
"version": "1.0.0",
"dist": {
"type": "zip",
"url": "https://acme.com/packages/anvil?key={%ACME_KEY}&version={%VERSION}"
},
"require": {
"ffraenz/private-composer-installer": "^5.0"
}
}
} In Composer 1.0:Composer resolves dependencies, iterates packages while dispatching During the During the 2. Breakdown
In Composer 2.0:Composer resolves dependencies, writes to the lockfile, downloads the packages while dispatching As a result, the package version is missing from the lockfile, the cache key, and the processed URL. 3. Breakdown
As of d91f7fa, your plugin throws Even if we ensure the version is injected at this step… 4. Snippetpublic function handlePreFileDownload(PreFileDownloadEvent $event): void
{
$processedUrl = $event->getProcessedUrl();
if ($event->getType() === 'package') {
$package = $event->getContext();
if ($package instanceof PackageInterface) {
$filteredUrl = $this->filterDistUrl($processedUrl, $package);
if ($filteredUrl !== $processedUrl) {
$processedUrl = $filteredUrl;
$package->setDistUrl($filteredUrl);
}
}
}
$filteredProcessedUrl = $this->filterProcessedUrl($processedUrl); …the lockfile URL and cache key are already set. At this point, on my end, Composer fails to unzip the archive and I end up with an empty folder at This is the roadblock I'm at. I think symfony/flex might have some practical ideas on how to move forward. |
…the plugin API Co-authored-by: Chauncey McAskill <chauncey@mcaskill.ca> Co-authored-by: Viktor Szépe <viktor@szepe.net>
Co-authored-by: Chauncey McAskill <chauncey@mcaskill.ca>
Hi @mcaskill, I completely missed the change in the Composer 2 workflow that renders the current strategy completely useless. Thank you for taking the time to break it down in a very detailed way. I guess I need to go back to the drawing board to see what we can do about it. |
This recent issue is tangentially related with our situation: composer/composer#9209 |
@mcaskill please report an issue on composer about the cache key issue, that definitely seems like something we'd want to fix if possible. |
@ffraenz |
Recently this PR got a green way php-coveralls/php-coveralls#296 |
Any updates with this? Pretty much stuck with |
@ffraenz Actually you can use that GitHub action in the final step :) |
@alexkerber A release supporting Composer 2 will be available shortly. |
We are stuck with several projects because of this issue :) |
Same roadblock here. For the time being I'm using
As seen here. |
If you remove the vendor directory (or the global plugin) you should be good to go. |
I had tried removing just Would I be using Also what do you mean, please by |
https://github.com/ffraenz/private-composer-installer#dependencies
You may have installed this plugin globally. |
Checklist:
composer/composer ^2.0
while maintaining support forcomposer/composer ^1.0
(Support for Composer 2 #23)vlucas/phpdotenv ^5.0
while maintaining support for older versions (Update dependency vlucas/phpdotenv to v5 #29)