[Zancarius]

> I never install Python packages outside of a virtualenv.

Global site-packages is all fun and games until someone loses an eye (or a dependency).

I had a fun learning experience with a large Python package once while trying to mix and match dependency versions, simultaneously trying to avoid clobbering the ones already installed by pacman. Without a virtualenv, it quickly becomes impossible to guarantee you won't break something in the process of installing something else. I never made that mistake again.

[hobarrera]

You really shouldn't install global packages circumventing the package manager (this applies to python and everything else really). You're just asking for eventual breakage, or leaking obsolete files.

[Zancarius]

Exactly. In retrospect, I'm actually not sure I've done something quite so stupid in a long time. However, I'm sure I did it ~10 years ago on Gentoo and/or FreeBSD when I was much stupider about dependencies. Either way, what I should've said is outlined below in my last paragraph, and mostly what I mean by polluting global site-packages (with PKGBUILDs!)--and trying not to clobber things.

As an aside first: I sometimes make a PKGBUILD for most things just on the merit that it's better for pacman to manage site-packages on its own--or anything, really. It's a terrible idea to stuff things into global library directories that aren't managed in general (although incautious use of things like npm or pip can certainly do that for you--still an awful idea).

However, I do recommend installing packages into a virtualenv for anything with modest complexity, because some applications have requirements/install_requires that lock specific versions which may not be mutually compatible with others, and there's also the circumstance where official packages aren't new enough but you still want the package manager to maintain the dependent package. I guess you could go with versioned packages in this case, but since the official ones will inevitably find themselves updated at some point, I see it as easier to circumvent the issue in the first place via a virtualenv.

Anyway, I did the above polluting nonsense once when building a package with quite a few dependencies: Trying to maintain a half dozen individual PKGBUILDs just for dependencies and pestering easily a half dozen other maintainers to update their respective PKGBUILDs versus modifying the application's setup.py (either with patch or sed) to match older versions were both terrible ideas and scaled poorly. It's far easier to simply build what's needed in a virtualenv and avoid polluting the global site-packages even with the package manager handling them on its own. This is especially true for complex applications with many dependencies that may already be installed (but with conflicting versions).

Sorry for the rant, you just reminded me and tickled all the right spots! :)