Use current Packagist v2 API endpoints instead of the now defunct v1 API endpoints. #153
Conversation
Bump guzzlehttp/guzzle from 7.9.3 to 7.10.0 Bumps [guzzlehttp/guzzle](https://github.com/guzzle/guzzle) from 7.9.3 to 7.10.0. - [Release notes](https://github.com/guzzle/guzzle/releases) - [Changelog](https://github.com/guzzle/guzzle/blob/7.10/CHANGELOG.md) - [Commits](guzzle/guzzle@7.9.3...7.10.0) --- updated-dependencies: - dependency-name: guzzlehttp/guzzle dependency-version: 7.10.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Bump composer/semver from 3.4.3 to 3.4.4 Bumps [composer/semver](https://github.com/composer/semver) from 3.4.3 to 3.4.4. - [Release notes](https://github.com/composer/semver/releases) - [Changelog](https://github.com/composer/semver/blob/main/CHANGELOG.md) - [Commits](composer/semver@3.4.3...3.4.4) --- updated-dependencies: - dependency-name: composer/semver dependency-version: 3.4.4 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
This change is needed because the v1 repository on repo.packagist.org is no longer available and thus this tool can no longer fetch meta data from it and thus calculate libyears from it, rendering it useless.
|
@WyriHaximus @SteveDesmond-ca @greg0ire @prajapati-kaushik did one of you already find the time to have a look at this? It would be greatly apreciated, since the latest release is broken 👍 |
|
It's on my radar, can hopefully get a new release out this week. |
SteveDesmond-ca
force-pushed
the
main
branch
from
ad981e8 to
3f40b2a
Compare
| $response = $this->http_client->request('GET', "$url/packages.json"); | ||
| $result = json_decode($response->getBody()->getContents(), true) ?? []; | ||
|
|
||
| // For the new packagist.org, override the deprecated metadata-url | ||
| if ($url === 'https://packagist.org') { | ||
| return new Repository($url, '/packages/%package%.json'); | ||
| } | ||
|
|
||
| return new Repository($url, array_key_exists('metadata-url', $result) ? $result['metadata-url'] : null); |
There was a problem hiding this comment.
Thanks -- everything else looks good, but I want to think a little more on this part...it feels off, but it's also been years since I've really worked with this app's code.
There was a problem hiding this comment.
Hmm yeah makes sense. If I find the time I will have a look as well if we need that URL compare at all.
|
I did a deep-dive into this today. It turns out the If you've hit a specific bug, feel free to add an issue. |
|
Yes I've hit a specific bug indeed, which can be reproduced by following the exact steps I outlined above, and can be resolved by merging this PR. Please see this screen recording if you can't or won't follow the outlined steps by yourself. Here you can see I run libyear against it's own repo to determine the freshness of this project, both with the latest version from master and my patched branch: In conclusion, the current release of php-libyear is still very much broken. I hope to find the time today to respond to your claim that the v2 URLS are already used if I can find the time. Signing off for now, @eXistenZNL. |
|
This is a useful fix, shame to throw it away... |
|
I dug a little deeper, as I would agree that the current version does not work with Packagist, which is likely the majority of use cases. The issue is that, at some point recently (maybe when they shut down v1 support), Packagist switched to using an absolute URL for their metadata pattern, where it had always up until that point been a relative one. The code can't handle that absolute part: it's just doing naive string concatenation. This PR works in the specific case with Packagist because it hardcodes an override for the new default host to use a relative URL. If a user has anything other than Packagist in their project, and that repo has an absolute URL for its metadata pattern, the same issue will occur, even with this PR. #155 has been created to track this and a new release with a fix for that should hopefully be out by the end of the week. For completeness, since it was mentioned again, the documentation URL provided before (https://packagist.org/apidoc#get-package-data) has 3 sub-headers in that section that show the different ways to get package info. |
|
Ah @SteveDesmond-ca thanks for having another look at this! I hope I didn't came across as too stern in my latest response, I was just disappointed that this was closed whilst the issue still persisted. For now, I think there is not much more for me to add or investigate, and and your own comment explains it all. Feel free to pick my changes directly or use them as inspiration for a fix from your side. Good luck with the new release, |
|
v3.0.0 just got released with this fix along with a couple small features. |
3 participants
Context
This change is needed because Composer v1 is no longer available as of September 1st, apparently this also means that the Packagist API got cleaned up and some endpoints were removed. It turns out that https://repo.packagist.org is no longer available which was still heavily used in this codebase.
For more info, see https://blog.packagist.com/packagist-org-shutdown-of-composer-1-x-support-postponed-to-september-1st-2025/ for more information on deprecating composer v1.
What has been done
How to test
Broken behaviour:
Fixed behaviour: