[nerpderp82]

> use your system Python.

Maybe you are an accidental accelerationist? Using the system Python is fastest way to a broken system and a broken Python.

[kaashif]

What? Why? How?

I always use the system Python plus virtualenv and that works fine, it's certainly never broken my system...

I don't even know by what mechanism that breakage would happen.

[w0m]

'sudo pip install <something huge with a ton of deps>' could potentially make system packages go wonky. Working inside a venv is perfectly safe.

[kaashif]

Oh, I guess I never even considered doing that for some reason.

If you just run "pip install" doesn't literally tell you to use the --user flag or virtualenv?

I guess it's probably an easy mistake to make.

[nerpderp82]

If you are using system python only to create venvs you are fine. As soon as you install or start modifying the system python in anyway, you are on the path to ruin.

[unmole]

Somehow in the 15 years of working with Python on Linux, I've never broken anything using pip.

[sigjuice]

Likely due to your good taste and judgement of never ever running pip with sudo.

[integricho]

I'd argue that running pip or any package installation with sudo is the devs fault.

[salawat]

Never tried to update something eh?

Debian is particularly bad because they'd comingle python 2 and 3 packages in the same filesystem locations if you used pip out of the box.

That was a horrid discovery on my part. I assumed, coming from java where this sort of thing has been a long solved problem, that no one would be daft enough to do something like that.

[Filligree]

God save people who don't know you're 'supposed' to use something else.

Most projects state something like "run pip install whatever", which people will then do. If you're lucky, it will ask for sudo. If you're even luckier, you stop to think before entering your password.

[nerpderp82]

I have a default Python env that my shell sources for every login shell. I can deactivate it and activate different envs on a per project basis.

That default Python env means I don't ever modify the system python for any reason. I type `python` and I get my own Python3 from the base.env

If you use homebrew, there are two settings that help keep your old python binaries around so that venvs that reference those old envs don't break.

HOMEBREW_NO_CLEANUP_FORMULAE, this takes a lists of packages to not cleanup

HOMEBREW_NO_INSTALL_CLEANUP, prevents old packages from getting removed

[deaddodo]

Node has the exact same issue for people who globally install all packages. The only differences are A) python makes environment management the dev's choice/responsibility and B) defaults to system vs environmental.

I actually far prefer the Python method to, say, Go's GOPATH. But, I far prefer Rust/Cargo to either.

[unscaled]

Sure, GOPATH really sucked, but that's why we got Go Modules. I don't think it's fair to compare Python to Go anymore.

I wish Python got a standard integrated solution for package management that works.

pip doesn't cut it in my book since it doesn't let you specify dependencies reproducibly. It either doesn't support lockfiles or ONLY supports having a lockfile, without dependencies.

venv also doesn't cut it since you have to remember to explicitly activate it and keep track of which venv is activated right now.

If we take a look at the much-maligned Node.js+npm, it's still far better than what built-in tools in Python let you have. Yes, Node.js doesn't provide full isolation from globally-installed node_modules, but at least it supports a local node_modules directory and lets it take preference. Notably Node.js+npm, with all its warts, doesn't suffer from the the two issues I've mentioned above.

[noloblo]

Golang is far better when it comes to go path and compile speeds