PyTorch and the PyPI supply chain

But trying to coerce setuptools to do what you want it to do is not fun. Its code is an undocumented mess, its abstractions are leaky and incoherent, and its architecture like a Jenga tower resting on top of a pile of Mikado sticks. Look at nontrivial setup scripts bundled (e.g., for project such as numpy or tensorflow): they resemble ancient incantations much more than actual code.

So I do not envy pip's job. But much of what ails setuptools also seems to have infected pip: its documentation is ... terse, to say the very least, its code isn't great either, and it does like to act and fail in ever-surprising ways. Moreover, coming from Rust or Julia, it is very hard to be satisfied with the hodgepodge of virtualenvs one has to set up in case of dependency conflicts. So, respectfully, it seems in character that pip does something sub-optimal and I think a doc fix is not going to fix those deep structural issues. (Anaconda, while certainly well-intentioned, tends to make everything worse, particularly on supercomputers.)

I understand that pip is in a tight spot now with respect to backwards compatibility.
Hopefully new projects (such as poetry) will improve this, I have to say, rather sorry state.