For me pipenvs only selling point is that some people don’t know about python -m venv.
I only use pipenv on a work project with a hundred dependencies, and venv on one other large side project. Everything else is installed with --user, especially dev tools like black and pyflakes. The user folder gets cleaned up every few years when you upgrade to a new version of python (rm ~/.local/lib/python3.5).
Has worked fine for a decade or two, no conflicts. I think some folks get spooked at python packaging and overcompensate in response, but it's pretty easy to troubleshoot when you've learned how it works.
Quickly noticing my mistake in being driven to play with shiny, new toys, I went back to my old tried-and-true pip + virtualenv for local development and plain old pip inside docker.
I think part of the drive around changes to Python packaging standards and tools has been inflated by a poor understanding and poor usage of existing tools.
Take setup.py for example - nearly everything you read in Python pushes using a requirements.txt file in your project. Why not define your project as an installable package with its own hard requirements - that are defined in your setup.py - and leave the Pip requirements.txt strictly for additional development/test dependencies? Or, maybe better, put test requirements in tests_require?
Nothing against Kenneth, but a big part of me wishes there were more anonymity in the open-source community. It's too easy for a single, well-known individual to come in and publicize <something> and everyone jumps on the <something> bandwagon without realizing that <other-thing> already exists, works well, and is an established standard.
But I hate pipenv, so much.
The basic idea of pipenv, being able to resolve the dependency graph more cleanly and precisely, is far far far better - but there are still some usability improvements that leave something to be desired.