They can be installed at the system level, making the package available to any Python program on the system. This can get problematic if not all of your Python usage can function with the same versions of all system-installed packages.
They can be installed at the user level, sitting in your homedir instead of somewhere under /usr. This gives some isolation from the system defaults, but may just move the problem down a level - you still have the potential for version conflicts.
They can also be installed at the virtualenv level, and now the package install is specific to Python programs launched from that virtualenv. Upgrading a package can only break stuff in that virtualenv, it can't spread beyond it.
If you mostly use stuff from the standard library and stable packages that don't change their APIs much, you can go a long way without venvs before it actually bites you.
It's _great_ as a system, but for the love of $DIETY, why isn't there some sort of way to say: `sudo apt install $ALL_THE_COMPILERS@[latest||version]` ...semi-similarly to the "exceptions" made for frequently updated packages like `firefox`, `chromium`, etc...
I know of `asdf`, but it seems like a big miss that it's sometimes so hard to use debian "properly" (ie: via `apt ...`) to actually develop.
Or similarly, wouldn't it be great if similar to `LSP-language-server-protocol`, there was something like `PSP-package-server-protocol` where `npm`, `go.mod`, `pip`, etc... were all like: "yeah, the debian system packages for python, perl, etc. are great for debian-on-debian", but we should also support pulling an arbitrary project at an arbitrary version and make a best-effort attempt at being able to isolate, share, manage, upgrade packages between them.
From my experience, I'd recommend sticking with debian packages for everything if possible (they may be outdated, but might still work).
Altenatively, you can also cheat a bit, use docker to separate your dev environment from your system.
I always recommend rtx.
If system package managers could support the same use cases as packages managers for your favorite languages then the latter wouldn't need to exist.
Distribution maintainers have a very different idea of how dependencies should be managed than most developers using those package managers do.
sudo pip3 install bar_bar_bar
...depends foo_foo_foo@v4.5.6
...but debian-configure-thingy.py expects foo_foo_foo@v1.2.3
(or import path conflicts or whatever)