4 ms·

That’s correct. Things only break if you pip install setuptools into the Debian-provided Python globally, not if you use both system-provided setuptools and pip

That’s correct. Things only break if you pip install setuptools into the Debian-provided Python globally, not if you use both system-provided setuptools and pip, nor if you pip install setuptools into a venv. 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. I would’t say it’s a non-issue though. There are so many instructions out there that recommend `sudo pip install -U pip setuptools`, and Python packaging developers take all the blame when the spacebar no longer overheats the CPU. This situation is, in some way, a microcosm of how people get the impression that “Python packaging is a mess”.

jnxx 6y ago
> 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.
ptx 6y ago
The problem is with the instructions then. So it's an issue in practice only because novices are given bad instructions, without the proper context, that tell them to do things that are known to be a very bad idea. Similarly, most software used to tell you in the README file to do a "make && make install", sometimes installing into /usr/local but not always. If a user followed these instructions and overwrote half of their distro-provided /usr/lib, things would break in the same way for the same reasons. The solution is to not do that. Don't mix distro-provided files with things installed from other sources. (As for the problem of people providing bad instructions, I don't know the solution. Perhaps remind novices that all instructions come with an implicit context and may not apply fully to their specific case?)

jnxx 6y ago

> 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.

ptx 6y ago

The problem is with the instructions then. So it's an issue in practice only because novices are given bad instructions, without the proper context, that tell them to do things that are known to be a very bad idea. Similarly, most software used to tell you in the README file to do a "make && make install", sometimes installing into /usr/local but not always. If a user followed these instructions and overwrote half of their distro-provided /usr/lib, things would break in the same way for the same reasons. The solution is to not do that. Don't mix distro-provided files with things installed from other sources. (As for the problem of people providing bad instructions, I don't know the solution. Perhaps remind novices that all instructions come with an implicit context and may not apply fully to their specific case?)