Compatibility with Composer V2 Spec

[Naugrimm]

Support for Composer V2 has been incorrectly added.

Repman currently returns:

curl https://token:$ACCESSTOKEN@$HOST/p2/$VENDOR/$PACKAGE.json | jq

{
  "$VENDOR/$PACKAGE": {
    "1.0.0": {...}
  }
}

According to the spec, the package must be wrapped in a packages object. So the expected response would be:

{
  "packages": {
    "$VENDOR/$PACKAGE": {
      "1.0.0": {...}
    }
  }
}

[giggsey]

Does composer display any warnings or other signs that it's not happy with the response? And what impact does it have for clients?

Edit: Just had a quick look at a composer v2 update, and it only required org.repo.example.com/packages.json, because it's providing the entire package list. So it never actually requests the v2 provider URLs.

[xvilo]

@giggsey that looks at the user agent, so if you call it in the browser without the proper v2 user agent you will get the v1 response as a backwards compatible measure

[giggsey]

@giggsey that looks at the user agent, so if you call it in the browser without the proper v2 user agent you will get the v1 response as a backwards compatible measure

I was using composer v2 (update --dry-run -vvv)

[Naugrimm]

@giggsey The composer command line program works flawlessly as it does not request the problematic URLs.

The issue came up, when I tried to set up The Renovate bot on our Gitlab instance. Renovate first loads the /package.json (works) and then two package-specific URLs:

192.0.2.1 - token [26/May/2023:11:13:37 +0200] "GET /packages.json HTTP/1.1" 200 1758428 "-" "RenovateBot/35.102.0 (https://github.com/renovatebot/renovate)"
192.0.2.1 - token [26/May/2023:11:13:43 +0200] "GET /p2/vendor/package.json HTTP/1.1" 200 23823 "-" "RenovateBot/35.102.0 (https://github.com/renovatebot/renovate)"
192.0.2.1 - token [26/May/2023:11:13:43 +0200] "GET /p2/vendor/package~dev.json HTTP/1.1" 200 23823 "-" "RenovateBot/35.102.0 (https://github.com/renovatebot/renovate)"

This issue/the linked PR is for fixing the latter two URLs.

[giggsey]

@Naugrimm Thanks. As a separate issue, I think it'll be good to fix the package list from V2 clients, so they can use the package URLs instead.