Cargo 0.28.0 and later break cargo-bloat for embedded

[therealprof]

As reported in RazrFalcon/cargo-bloat#25 I upgraded cargo-bloat to the latest version which also bumps the cargo dependency to 0.28.0 and this seemingly breaks cargo bloat for use on cross-compiled binaries. I verified that bumping the dependency to 0.29.0 does not address the issue while going back to 0.27.0 rectifies the problem.

[alexcrichton]

Thanks for the report! We don't provide stability guarantees though about Cargo used through its library API. To that end we're happy to take PRs but we don't track the issues like this here unless it's a bug with Cargo-the-CLI

[therealprof]

So this is it then? A valuable tool breaks, the author can't fix the problem because it's in a third party component and the authors of a third party component won't even look at the problem?

Frustrating...

[dwijnand]

As a solution going forward, perhaps it's worth having a CI build (either during PR validation and/or a nightly build) that tests against latest/source cargo? The idea being that you would have forewarning when a breaking change lands.

Maybe it should be a best practice for cargo extensions (custom commands, or whatnot).

[therealprof]

It's certainly a good idea to do that but I don't see how it addresses the problem. Say you're forewarned about an upcoming compatibility issue, what are the options? Staying on the old version indefinitely? And then let me ask the same question again but with the background that the tool we're talking about just so happened to work for embedded development without any intention to enable that use case in the first place.