@greg0ire is this related to#26972 or could help us implement that idea? Thanks!

It is slightly related, and it is a step towards a second attempt at doing#24867, which is deeply related, and might help you implement that idea.

To sum things up, there is vendor code code and your code. This PR makes the distinction between your code calling your deprecated code , and your code calling deprecated vendor code.#24867 is about a third category: vendor code calling deprecated vendor code.

I don't think this segregation makes sense: your code is always the root of any calls made to vendors.
Take e.g. Yaml deprecations:you write the yaml config or call the parser, andthe Yaml component calls the code that triggers deprecations, leading to false-negatives.
I'm 👎 with this reasoning.

your code is always the root of any calls made to vendors.

It very much is, but you can get deprecations without any calls made to your vendors, and if you do, that's probably the deprecations that should be fixed in priority, especially when you are a library, because it means you are calling your own code in a deprecated way

Maybe it's a matter of vocabulary: vendor vs not-vendor means little to me as I explained, but direct vs indirect makes more sense to me.

This is not a segregation between direct and indirect, it's a segregation betweensrc -> src and (src -> vendor orvendor -> vendor), or, as you'd call it, between internal and (direct or indirect, but vendor)

According to#28048, it could make sense to group deprecations in 3 groups (in this order):

• in app (=triggered in src/)
• calling vendors (=direct deprecations when src/ calls something in vendors/)
• remaining (=indirect deprecations, e.g. related to config/)

Maybe also implement the thresholds discussed in#28048 here?
A screenshot would help btw at some point :)

I can do all this, but to be clear, the segregation already exists, it is just that it is restricted to theweak_vendors mode only, and this PR lifts that restriction.

Here is how it looks right now:

fewer tests for the weak vendors mode, which I plan to replace with different exit codes

you cannot replace the mode by something switching the exit code. any non-0 exit code is a failure, and CI would break on them. Having to replace theweak_vendor mode by a wrapper command checking the return type to make it 0 in some cases would be bad DX.

Another idea could be to produce a report in an easy-to-parse format and let people act on it if they wish to.

Unless someone needs that IRL and is willing to implement, that possible, but we're not looking for more code to maintainà priori. :)

Rebased without the comment about exit codes

@greg0ire@nicolas-grekas How do we move forward on this one?

I'm currently working on an implementation of#28048 , and it would make my life easier if this got merge, so I'm going to rebase this again, and hope you accept to merge it.

I'd suggest borrowing this PR is your work.
It cannot be merged as is to me.

Ok