> IMO neither party really did anything wrong, the situation is caused by users depending on implementation detail that used to work but no longer does. Slight

> IMO neither party really did anything wrong, the situation is caused by users depending on implementation detail that used to work but no longer does. Slightly exaggeratting, but in the same way, you could say "the designers of the C language did nothing wrong with creating that much undefined behavior, any competent programmer just needs to know what they can do and what not". I am not blaming the developers of setuptools or pip which have very limited resources. But the solution they created so far is just not good enough, and its technical properties contribute to these problems. And other language environments clearly do it better. Another aspect is that the community accepts libraries which break backward compatibility. This will become an ever increasing problem as soon as it becomes more frequent that programs rely on different libraries which in turn happen to have indirect dependencies which require conflicting versions of the same thing. There is no way to resolve that in Python. It would be much better that libraries which break backward compatibility would get a different name altogether each time, because in this case you could include the different libraries in the same program. But Python's library authors don't, and this is probably because they want people to keep using their library by given the mere impression that it is compatible, while it is not. And this is just not honest communication. If you break compatibility, you should tell the users of your library. Or better even you don't break it in the first place.