For folks wanting to see the scope of a true “all in one” tool, the one we reference from the end of https://packaging.python.org/tutorials/managing-dependencies/ is hatch , since that covers project templating, release management, etc.
The main problem with “all in one” tool proposals is that they can only have one default behaviour, and that’s OK if you’re able to get in early into a relatively new ecosystem (as folks that don’t like the defaults will self-select out of the ecosystem entirely), but mostly doesn’t work for getting adoption in an established ecosystem.
pip was only able to pull it off because it was try to replace a specific existing tool (easy_install) that had defaults that were a long way from what most people wanted, and the switching costs for that usage model had been deliberately kept low.
By contrast, most of the tools we have now are explicitly making different core design assumptions. For example:
- hatch: provides answers for everything Olek wanted an answer to when designing a project management process
- pipenv: dependency management that doesn’t assume the project itself is a Python component, but does mostly assume one target environment per repo
- poetry: dependency management that does assume the project itself is a Python component
- pip-tools: a lower level DIY dependency management toolkit that doesn’t make any more workflow or target environment assumptions than pip itself does