Personally it's the interactions between the life cycle management of the virtual environments and bulletproofing for use by all team members. For any non-trivi

Personally it's the interactions between the life cycle management of the virtual environments and bulletproofing for use by all team members. For any non-trivial Python project, I end up with at least 2 virtual environments, one "normal" and one for installing unit tests/linting/other static checkers. If you're environments are already pull this project and goes to `make lint`, is the lint virtual environment extant, does it have all the required dependencies, and are those steps idempotent so as not to trigger a setup on every run. And then add on edge cases like, what if someone already had a virtual env active when you went to do the setup, what edge conditions does that introduce? Do you add something to your logic to detect extant virtual environments and deactivate them before trying other actions. All of these problems are solvable of course, but at what level of effort and for what benefit? And you pay all these costs every time you want to change something, especially if you've got to explain all the hacks to someone new, and you always run the risk that it works for you but not in a clean environment.