@diazona @RomanOnARiver
One brief note: when David says the "new way" is to use Python virtual environments, that's extremely relative. It has been best practice (and the only way to save your sanity because of dependency hell in any nontrivial project) in the Python community for, I dunno, 20 years? But Python's been around for >30, so it is the "new" way. Long before the `virtualenv` tool I was accomplishing the same thing with symlink trees to isolate interpreters.
There are lots of opinions on where you should keep your venvs, i.e. what the path to them should be. I personally like putting them in the project directory, typically `<project>/.venv`, but others like to stash them away someplace, like in ~/.local/share. Project tools that handle virtualenv management (e.g. poetry, uv, etc) will generally give you a way to control where they create the venvs.
#DependencyHell #import #circular #conflict