v189 #461
Merged
v189 #461
Conversation
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
mkrepo.sh has to sort all packages by their "heroku-sys/php" version requirement in descending order this is due to an internal implementation detail of Composer's repository data structure, in which e.g. "ext-memcached" in version "3.1.5" is stored multiple times: once for PHP 8.0, once for PHP 7.4, once for PHP 7.3, and so forth. If a composer.json now has a requirement for "php: *" and "ext-memcached: *", and "ext-memcached: 3.1.5" in its variant for PHP 7.0 (expressed in turn as a dependency on "heroku-sys/php: 7.0.*") comes first in the list of packages, this would result in PHP 7.0 getting installed instead of a later possible version. Until now, all packages, if they used a PHP version requirement (that's only the case for extensions, commonly), expressed that as "7.4.*" or similar. A package might, however, also want to express the version requirement differently. That's not useful for extensions, which are compiled against a particular PHP series, but for e.g. Composer, we want to say "5.3.2 or later", etc - and for a future Composer version, "7.2.0 or later" if it requires that, and then have the solver automatically pick something older for folks stuck on an older PHP. We use Python's distutils.version.LooseVersion for a rough comparison, since the version strings might contain all sorts of things (e.g. "^7.2.3 || 8.0.0" or whatever), most notably that asterisk. However, comparing ">=5.3.2" against e.g. "0.0.0" fails with a str vs int TypeError. Why would one side of the comparison be 0.0.0? Because that's the default if the "php" requirement is absent. So when changing e.g. the Composer package from no version requirement to ">=5.3.2", the repo couldn't be generated, since there is an older manifest with no requirement at all, and now its "0.0.0" default is compared against ">=5.3.2", which TypeErrors. The solution is to just replace anything that looks like a version specifier with a zero, since we're not comparing exact versions, we just need to roughly sort.
This is just a nice-to-have, since all of our PHPs satisfy all these requirements, but if that ever changes, this will help catch it.
edmorley
approved these changes
Feb 5, 2021
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.
The usual version updates, and some polish for Composer's package's PHP version requirement and associated handling.