Agreed. Pipenv only led to confusion and pain for me. Last time I tried to use it in a project led to not knowing what the heck to do once I wanted to in my doc

Agreed. Pipenv only led to confusion and pain for me. Last time I tried to use it in a project led to not knowing what the heck to do once I wanted to in my dockerfile - do I install pipenv inside docker? what's the point of that? Is there a tool to convert this Pipfile to a requirements.txt file to use with plain 'ole pip or what? 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.