[viraptor]

I linked the example here https://news.ycombinator.com/item?id=22186046

But tlrd is: if you "apt install some-utility", then "pip install something else", you may have upgraded packages that some-utility relies on but is not compatible with the new version anymore.

[mixmastamyk]

Pip and apt install to different folders already. In the very unlikely event there’s an issue in a container the solution is simple, modify the sys.path. The other 99% of the time avoiding the venv is a win.

[viraptor]

Sure it's unlikely, but it happened at least once now, and that's exactly the situation venv is designed to avoid. Pip and apt install to different places (by default/convention), but you end up importing the pip version by default. You can change sys.path to work around it of course... but that's pretty much what virtualenv does anyway. Utilities by default do not change that path which leads to issues like the linked one.

I'm not saying never install globally, just let's keep in mind that this can lead to real issues which may be very surprising / hard to debug once in production. Unless you understand exactly what and how is delivered with every change, defaulting to venv is a safer option.

[mixmastamyk]

Complexity on top of complexity makes things harder to debug in my opinion. I’ve never had trouble debugging library issues and they’ve never happened to me in a container. Even easier is to not mix tools in a container anyway. Less is more.

[viraptor]

It can be a tool used as a dependency of your app. And I feel like you can make the same claim about locks. They just introduce complexity and make debugging harder, race condition never happened to me anyway... It's about ensuring edge cases don't bite you when you don't expect it.

If you can prove it doesn't apply, then sure, why not install globally.