The python core team endorses pip, but pip solves something like 80% of the problem - we need them to endorse the other 20% of the solution.
I've been using pip-tools for some time, I think it solves the other 20% of the problem for me in a simple way that I like. Poetry et al seem to be trying to do too much - ymmv.
The iterations on packaging that don't really seem to ever get it right are, I think, frustrating to the community where the core likes to advertise a "Zen of Python" "one way to do things" mantra, but can never really get 100% of the packaging problem sorted out in a clean way in spite of several communities seeming to figure it out.
The core team endorses everything, not only pip, but good luck finding an example setup.py with example repositories from any of the documentation pages you find on Google. It’s results 1-3 and is always marked Obsolete.
The communication on what to do is a disaster. Look at non obsolete https://packaging.python.org/en/latest/tutorials/packaging-p... - my dude, their pyproject.toml doesn’t even specify a dependencies section, which is 99% of the value proposition of packaging.
I have been impressed that they're making progress though - wheels solve some problems conda used to solve; so doing ML stuff that is based on conda I can usually just use regular pip packages now which is very nice.
I like that pip-tools is a separate thing. Most Python packages don't need and shouldn't use a requirements.txt file. It makes more sense for npm to have it by default, but not Python.
I kinda see myself wanting the pip-tools flow, requirements.in -> pip compile -> requirements.txt thing perhaps integrated into pip itself. Seems like the simplest of the solutions out there for good dependency declarations and pinning? I may well be wrong.
It is, but it doesn't really bother me that it's not part of pip itself. On the other hand, I wouldn't be opposed to it being part of pip and "blessed" in that way.
I've been using pip-tools for some time, I think it solves the other 20% of the problem for me in a simple way that I like. Poetry et al seem to be trying to do too much - ymmv.
The iterations on packaging that don't really seem to ever get it right are, I think, frustrating to the community where the core likes to advertise a "Zen of Python" "one way to do things" mantra, but can never really get 100% of the packaging problem sorted out in a clean way in spite of several communities seeming to figure it out.