> Anyway, this kind of thing is only useful if people adopt it. The people who are likely to install this tool and use it probably already avoid this issue while the people who have this issue will never hear of this tool or will not consistently employ it.
I could see projects adopting this, or something like it, in their CI pipelines.
Both for open source projects, but also at companies with a lot of internal repositories with Python code – especially if it is common that other people with little experience for some repo contribute code to it.
In the case of an open source project if it’s a popular repo that a lot of people are users of and different people frequently contribute to for the first time.
And in the case of company internal repositories, if it’s code that different teams only touch now and then, with only a smaller group of people intimately familiar with all of the inner workings of the code and the other people being mainly focused on other repos in the company but still having to sometimes contribute changes because their code is relying on the code in that other repos.
I could see projects adopting this, or something like it, in their CI pipelines.
Both for open source projects, but also at companies with a lot of internal repositories with Python code – especially if it is common that other people with little experience for some repo contribute code to it.
In the case of an open source project if it’s a popular repo that a lot of people are users of and different people frequently contribute to for the first time.
And in the case of company internal repositories, if it’s code that different teams only touch now and then, with only a smaller group of people intimately familiar with all of the inner workings of the code and the other people being mainly focused on other repos in the company but still having to sometimes contribute changes because their code is relying on the code in that other repos.