The best practice, which prevents this issue, is to use envs, (as well as pinning your dependencies for any given project in a committable artifact).
(Seems like a lot of people are using system Python, which isn't really recommended.)
The best practice, which prevents this issue, is to use envs, (as well as pinning your dependencies for any given project in a committable artifact).
(Seems like a lot of people are using system Python, which isn't really recommended.)
I really like the language, but all the tooling is seriously broken.
Fwiw what I've settled on that seems the most stable is to use pyenv as the "outer layer", as it shims the python interpreter along with any venvs so you don't get conflicts / heisen-incompatibility. Lets you use anaconda envs as children as well. The real trick, I think, is to pick one system as the canonical master env controller and don't deviate.
The whole idea that you need a multitude of environments to support applications written in the same interpreted language is where it breaks, that should not have been necessary if backwards compatibility had not been an issue.