composer diagnose complains about "non standard installation"

[fcool]

If one runs composer diagnose the output is:

Checking platform settings: OK
Checking git settings: OK git version 2.43.2
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com oauth access: OK does not expire
Checking disk free space: OK
Checking Composer and its dependencies for vulnerabilities: WARNING
Could not find Composer's installed.json, this must be a non-standard Composer installation.
Composer version: 2.7.4
PHP version: 8.1.26
PHP binary path: /usr/lib64/php8.1/bin/php
OpenSSL version: OpenSSL 3.0.13 30 Jan 2024
cURL version: 8.7.1 libz 1.3 ssl OpenSSL/3.0.13
zip: extension present, unzip present, 7-Zip present (7z)

The question now is: do we care? If so, I would look into our ebuild to see, if we can convince composer that our install is "standard" ;)

[r7l]

This message seems to be ok for me. Unless i am wrong, the standard install is downloading the file and copying it to /usr/local/bin or something. As sad as it is, our install is not standard. Even more so with the Fedora Autoloader, which goes against the idea of Composer in general. They don't even support our idea of using another package manager. See here: https://github.com/composer/composer/issues/4950 (Especially the closing comment)

Another alternative would be patching this line and fix the error but i can't even find the file in my local install.

Or we just change the message and tell people it should be ok.

[fcool]

I've just took a deeper dive into this topic... woah... rabbit holes everywhere.

So for now I am completely fine with leaving the message as is - as it is correct. This is not the "composer default" way to deliver a "package". But ours.

A "nice" alternativ in my opinion could be, not to patch out the detection, but patch the error message into something like:

The above warning results from installing composer without relying on composer being available through portage. You are fine.

Creating an "installed.json" would never really work // causing rebuilds of composer if any of its dependencies would be updated, etc... something we do not want. At least I currently think, I do not want. ;) Of course we could store a fixed "installed.json" to make the detection happy - but we would convince composer to lie then about the internally used package versions. For that I really would prefer not to lie. If composer is installed by portage, you are always able to ask portage for the used versions, etc.

[r7l]

The alternative with the message should be ok. We should keep this as simple as possible as upstream might change this in future.

[fcool]

Final proposal for the message:

You installed composer through portage and not through composer. If you need to know about composers dependencies, you can ask portage. It is safe to ignore this warning.

[r7l]

My suggestion:

Composer and dependencies are managed with Portage. Checking vulnerabilities with Composer is not supported. Please make sure to install the latest version or report missing updates to https://github.com/gentoo-php-overlay/php-overlay

I wouldn't add statements about safety as we don't want to have liability.

[fcool]

absolutely valid point!

Minor modification:

Composer and dependencies are managed with Portage. Checking composer's vulnerabilities from composer is not supported. Please make sure to install the latest version or report missing updates to https://github.com/gentoo-php-overlay/php-overlay

Background: Of course composer's security checks still work for your own projects. They do not work, for composer itself

[r7l]

The only thing i would change is Composer being name and should be uppercase. Otherwise good work!