I'm still a bit confused how #2895 gets past CI with all those unnecessary changes to the api files.

I'm still a bit confused how #2895 gets past CI with all those unnecessary changes to the api files.

I'm new to the public API process/workflow so I'm not sure how it should look, but should it be updating the API files with more changes with than the 3 lines that it has? When I ran just check-api with the wrong version of cargo-public-api, it generated ~1700 lines of changes in ba2ef0e36920d17556727a21e5f292e67da776a6, which seemed way off to me. It led me to look deeper and use an updated version of cargo-public-api that resulted in the 3 lines of API file changes

The api file changes in #2895 look correct (FTR the actual PR is not correct IMO but if it was the api files would be correct).

I have sort of concept NACK on this. The API changes should be committed by a bot, not contributors which would also obviate the need to install anything and thus getting the installation wrong. Your time is better spent automating it than writing instructions for people to do manual work.

We have new contributors not knowing how to install the tool so they can use it to patch master as of today. I understand you don't like the whole check api thing but nacking docs because of it seems to be hindering other devs.

How many contributors did we lose because someone looked at it and though "I need to install an external tool god-knows-who programmed, screw that"?

I mean, sure, write better doc now, this is just a super bad solution. I'd rather deal with resolving conversations than this crap.

I agree with @Kixunil, maybe we can add to the contrib/check-for-api-changes.sh:

check_and_install_cargo_public_api() {
  if! cargo --list | grep -q "cargo-public-api"; then
    cargo install cargo-public-api@0.35.0 --locked
  fi
}

What do you think?

Closing because of #2912

What do you think?

While it's in-principle acceptable for a shell script to do literally anything, I find it surprising and obnoxious for it to install things on my system.

How many contributors did we lose because someone looked at it and though "I need to install an external tool god-knows-who programmed, screw that"?

The API tool greatly helps with review and maintenance. It definitely outweighs the theoretical loss of any drive-by contributors. If we lost you over it, that would be a net loss obviously. But so far you are the only regular contributor to this library who has complained about it.

The API tool greatly helps with review and maintenance.

Funny, I find it too noisy to be practical (but I only used it a few times so far). E.g last time I got suspicious in the infallible derive xpub PR went to the API changes, found the change in millions of lines but then had to go back anyway to find the exact fn that was changed and read its body. I would've saved time if I searched for it in the whole code diff directly without going through API list.

Note that I'm not denying your experience, I'm just sharing mine.

If we lost you over it

Kind of? I already have crazy little time to contribute and dealing with more stuff makes me want to put off doing PRs and stick with reviews for now. I'll likely do PRs at some point anyways since I have some ideas that may be easier to PR than explain. :)