-
Notifications
You must be signed in to change notification settings - Fork 672
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
Force usage of latest patch version to avoid JIT bugs #11270
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
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.
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.
Please just declare
composer.json
"conflict"
ranges next time: this has caused me quite a few headaches, yesterday.I'd rather get an older psalm version, than one that crashes at startup.
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.
Thing is, the version bump was made for a specific reason, to avoid crashes and other subtle bugs that would have caused more lost time in pointless debugging than a simple PHP version upgrade...
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.
From a consumer perspective, a conflict range would've made this clear, and could've been relaxed until a bugfix is applied (if that would ever allow relaxing the dependency range - it's fine to have the limit in place from here on).
A runtime crash is the worst of both worlds:
Early signaling here is
composer update
failing to get the latest release.The current effective result I have right now is me + other people I collaborate with having to manually go in
composer.json
and pinningvimeo/psalm
to an older release.In fact, I currently use
vimeo/psalm:6.4.0
(rollback) on all my systems, and addedvimeo/psalm:6.5.0
as an explicit conflict for my colleagues.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.
The problem with conflict ranges is that composer does not make them at all clear to users of a package; the dependency resolver simply works around them to fit the current version constraints, regardless of the side effects (bugs in older PHP versions).
This is not the only runtime check, and some requirements (like the VM overcommit requirements) cannot even be expressed using composer.
I will not be adding a dependency constraint to composer.json, because as I said, Psalm is a development tool, and the development environment is not as rigid as a production environment (to a certain extent, i.e. minor bumps will still be expressed using composer, as they are somewhat related to the production environment).
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.
We've been working this way for well over a decade now: not getting "latest" is fine, and
composer why-not
tells you so.I've even built an entire package around this: https://github.com/Roave/SecurityAdvisories/ - it's designed to exclude dependencies that are a hazard, and people do use it, consciously.
Runtime checks are 100% not the way, and amplify noise around this.
I (relatively experienced PHP dev) for sure wasted a lot of time yesterday dealing with this while trying to work on psalm/psalm-plugin-phpunit#149 - had to roll back
vimeo/psalm
tons of times while trying out dependency ranges.What moving this to a runtime check achieved here is:
composer.lock
upgrade pipelines ( @renovate / @dependabot ) will fail due to an invalid upgradeWhat should be done next?
The correct way forward here is:
"conflict"
Note that deleting a release is non-viable, unless it's a security risk.
"it's a development tool"
As for the "it's a development tool": it does not matter if it is - it's part of the dependency graph, and the dependency graph is designed to say "these work together" or "these don't work together".
In addition to that, even if the dependency graph is split between
--dev
and--no-dev
dependencies, the "these work together" should still apply for the--dev
part.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.
Marco, I value your input, and look forward to collaborating with you (will be taking a look at your PRs next week).
I am not too willing to die on this hill: in general, it's not about this specific change, it's about the possiblity for me as the maintainer of Psalm to direct users to make changes to their environment, to avoid them footguns when working with Psalm.
In my long time as a PHP engineer, I have always tried to proactively prevent bugs from even reaching users, guaranteeing the best possible experience when actually using my tools, be it using warnings to update to the last version on startup (like in MadelineProto, will probably implement this in Psalm as well, given that phpstan has them too), or using runtime exceptions for particularly bad platform bugs (i.e. did something similar for MadelineProto for a recent fiber-related bug, and @trowski did the same inside of amphp itself as well), or even automatic static analysis on code written by the users, to proactively detect possible issues.
I do not want users to waste time debugging weird exceptions and crashes caused by PHP bugs (like recently, I already got two new issues caused by a PHP bug on older versions of PHP, combined with the new amphp-based concurrency model).
A (patch release, not even a major/minor!) PHP version upgrade is a minor inconvenience, bypassable using any modern PHP distribution method (ondrej ppas on debian/ubuntu), and does not require any additional refactoring work on the codebase on behalf of users.
This is also the case for other runtime checks as well (such as #11218).
I am a user and great fan of your security-advisories project, because it allows library developers to bypass composer's long-time limitations, to prevent users from getting vulnerable/broken versions of libraries.
I am trying to apply the same rationale behind security-advisories to Psalm as well, using the only way I have available to me, given that we're talking about PHP platform bugs, and not issues with userland libraries.
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.
I feel like the message didn't come through, but I'm also just making a point, and not really willing to explain further than I already did :D
We should probably talk about it over 🍻 at PHPDay or such :)
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.
Ayy, now that's a nice idea!