Well when I'm doing data science at work, I typically work with conda environments, which then just work with runvenv because it finds them all. For my other "python -m venv" multi-use environments, I just stick them in ~/.venv, OR I drop a symlink in ~/.venv to them, so they're searchable, which makes ~/.venv into exactly an explicit registry by symlinks.

If it's a one-off environment for one program, I'll usually just make a venv and put it right next to the script. But the problem is I don't want the clutter of an environment in places that are in my executable path. So if I have something like a repo directory that has a python program and an environment, or ~/python with a python program and an environment next to it, then I just drop a symlink in ~/bin/ to the executable script, and now runvenv will follow that symlink, find the venv next to the script, and run it. So it kind of separates it. I can make my environments however I want or wherever I want with conda or venv, and the scripts using them are still directly executable. Either by adjacency to the script, or a symlink in ~/.venv to them (if I didn't make them directly in there). It doesn't functionally matter if they're accessed via a symlink, because the runpip tool takes care of handling that properly.