-
Notifications
You must be signed in to change notification settings - Fork 3
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
chore: fix phar.composer.lock
#24
Conversation
Built with php-8.2.11
The file is (and should be) autogenerated.
I don't think the |
Ok will try with that. |
Looks like it's still creating issues.
But OK, I'm a bit out of ideas on how to get this things working right now, Grumphp 2 will wait a bit before being packaged in Nix. I pushed this PR, we'll see what the other PHP maintainers will think. |
As you can see in the logs, only the composer API version differs now. Meaning you'll have to use the exact same composer version to validate the file that infused to build the PHAR or somehow disable that specific line during the validate command. Not sure either how we can do this tbh |
I could also just wait for the next point release, hopefully your composer version will be updated :D |
It might or it might not be :) It might make sense to ask the composer people how to deal with it? |
OK ! But what's preventing you to automatize generation of the We are always trying to use the latest stable version of Composer, we cannot use an arbitrary version of composer and/or maintain all the versions in the repository. This is not only specific to Nix, but in every distributions. Composer being the most important tool here.
So far this problem only happen with Grumphp. I doubt there will be similar issues with others... (yet?). I could fix the issue by providing patches, but I would have preferred fixing the problem within this repo than polluting |
I get that. I could upgrade composer before building the phar, but if you build your package a week later - and a new composer version bumps the API version in the lock file, your build will fail again. I'm rather suggesting looking into a more stable build process from your side, since that's the more time-proof solution. |
True if you use a version of Composer < 2.6.0. With the current version of Composer, the validation is failing. So to me, there's an issue with older versions of composer. Of course this is not critical, and we can still run
No, we can use different Composer version, but if the attribute But allez, no worries, I will just wait an update of Grumphp and in the meantime still use 1.15 or just provide my own As always, thanks for your availability, even if we haven't found the best compromise. |
I fixed the issue in Nix by providing 2 very small patches, find it here: NixOS/nixpkgs#262558 |
Allright nice. In any case, I'll update the script in order to download the latest composer before building. Probably something for next friday. I'll keep you posted. |
Thank you mate, ping me when you need me to check it out. |
Hello,
This PR relate to #23 and fix the
composer.lock
validation. There's no more discrepancies betweencomposer.json
andcomposer.lock
now.Built with PHP 8.2.11 and Composer 2.6.5