Python venv tools are the new JS frameworks: every day some other ridiculous tool is born.
And yes, everything is already solved with: due diligence (non-existent in scientific community) and nix.
And yes, everything is already solved with: due diligence (non-existent in scientific community) and nix.
In all seriousness, it is a bit tiresome when you come back to the python world and see a completely fragmented ecosystem (poetry, pdm, pip-tools, uv, and the older ways).
My personal view is that there "one standard tool" makes sense for users (i.e. people who will install applications, install libraries in order to create their own personal projects, etc.) but not for developers (i.e. people who will publish their code, or need to care about rigorous testing, published documentation etc.). The latter require the users' install tool, plus specific-scoped tools according to their personal preferences and their personal conception of what the problems are in "development" that need solving. That is, they should be able to build their own toolchain, although they might start with a standard recommendation.
Pip's scope has already crept in the sense that it exposes a `wheel` subcommand. It needs to be able to build wheels in order to install from sdists, but exposing this functionality means providing... half of a proper build frontend. (PyPA already offers a complete, simple, proper build frontend, called `build`; if `pip wheel` is part of your deployment process, you should probably be using `build` instead.)