Improve communication when the plugin is doing its thing

[igorsantos07]

Disclaimer: sorry if this sounds like a rant; I spent a lot of hours because of this and I'm trying to properly report the issue "under the hood", but after all of this I'm not on my kindest mood anymore and I'm unable to rewrite it any better :(

Description
When you install a dependency that requires this plugin without realizing what it does under the hood, you may very well be baffled by "why the hell is composer forcing this new weird dependency on my root requires??"

I spent a lot of time trying to understand what's going on, while I update a lot of old dependencies on our big project. I had to go through a lot of hoops and guesses, until I found --no-plugin and noticed the issue was "gone". Then, I ended up at #244, thinking this was my case, but the thread there was hard to follow without proper understanding of what the package is about. (Now that I'm writing about it, I wonder if the OP there also wasn't sure what this plugin does). I only grasped it all after checking the README. That's definitely bad DX - a library user shouldn't be required to read another library's doc to discover (sorry for the pun) why composer is "misbehaving". It's quite a long shot.

Example
It's confusing as hell when you do composer remove http-interop/http-factory-guzzle -vvv and it (1) removes it (2) reinstalls it (3) doesn't say one single line as to why it reinstalled that, even with the verbosiest flag. In my case, this is probably coming from Mailgun v3 - but then again, I'm unsure because it gets shoved in my root requires instead of being a dependency of Mailgun, and there's no way to tell why the extra package got installed if you're not doing a clean install of that dependency and have read what is expected to happen - or in the case the main dependency doesn't explain clearly the actions of discovery (which seems to be the case of Mailgun as well).

Check this meaningless output from composer

$ composer remove http-interop/http-factory-guzzle
./composer.json has been updated
Running composer update http-interop/http-factory-guzzle
Loading composer repositories with package information
Updating dependencies                                 
Lock file operations: 0 installs, 0 updates, 1 removal
  - Removing http-interop/http-factory-guzzle (1.1.1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 0 updates, 1 removal
  - Removing http-interop/http-factory-guzzle (1.1.1)
Generating autoload files
50 packages you are using are looking for funding.
Use the `composer fund` command to find out more!

Loading composer repositories with package information
Updating dependencies                                 
Lock file operations: 1 install, 0 updates, 0 removals
  - Locking http-interop/http-factory-guzzle (1.1.1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing http-interop/http-factory-guzzle (1.1.1): Extracting archive
Generating autoload files
50 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Found 20 security vulnerability advisories affecting 10 packages.
Run "composer audit" for a full list of advisories.

Suggestions
Easy solution: logging.
Once the plugin realizes it needs to install an extra package because a root dependency requires that, it must state that clearly. For instance, it could write to console "php-http/discovery noticed your dependency ABC needs an implementation for PSR-XX. Thus, we're installing XYZ on your root requires".

Complex idea: deeper integration within Composer:

• why: It would be awesome if this could be shown as a sort of peer dependency by composer why, but not sure about the feasibility of that through the plugin system. It doesn't help either with Composer not allowing any sort of comment on composer.json, so we can't even leave comments around the "weird" package, e.g. "this is here because it's a peer dependency of X".
• remove: Another issue is allowing the user to remove that peer dependency, only to have it reinstalled again right after - it's a very real "WTF moment". Would it be viable to block the removal of the required dependency without installing a substitute before that?

[nicolas-grekas]

Thanks for the feedback. Logging looks like a nice way forward.
Blocking the removal of a required dep is also likely possible but I'm not sure how easy or hard it can be; and anyway, logging would be nice so let's start with that.
Would you like to give it a try?

[igorsantos07]

Oh gosh. I came here to complain and now you also want me to do open source??
That's ridiculous.

I'll try to find some time next week 😂 No clue if I'll be able to achieve it decently, though - I never touched Composer internals that deep, but I think it will be worth a try.

Happy new year, sir!