To access 10 different commands at the same time, that is tricky but definitely doable.

First thing that comes to mind, you can use aliases.

To keep it simple, lets use 3 examples instead of 10: harlequin (this project), pgcli (https://www.pgcli.com/) and httpx (https://www.python-httpx.org/)

Setup a main home for all your venvs:

    cd ~
    mkdir venvs

Go into this dir, and create your venvs and install the packages

    cd venvs
    python -m venv harlequin
    ~/venvs/harlequin/bin/pip install harlequin

Now this binary is available at

    $ ~/venvs/harlequin/bin/harlequin

Repeat for the rest

    cd ~/venvs
    python -m venv pgcli
    ~/venvs/pgcli/bin/pip install pgcli

    cd ~/venvs
    python -m venv httpx
    ~/venvs/pgcli/bin/pip install httpx

Wash, rinse, repeat. Now you have all these binaries available and can alias them

    alias harlequin="~/venvs/harlequin/bin/harlequin"
    alias pgcli="~/venvs/pgcli/bin/pgcli"
    alias httpx="~/venvs/httpx/bin/httpx"

This is a pain in the ass though and usually simple CLI tools like this do not collide with each other. So that is why I say install globally, or install into your "global junk drawer" virtualenv.

Meanwhile, for actual projects that you are developing on, those would have their own isolated venv.

I have a junk drawer venv where I install tools like this. If something goes wrong, it is as simple as rm -rf the venv and make a new one. And then I have isolated ones for each of the actual systems I maintain. Again, I use pyenv for this to make it a little easier to manage in conjunction with their specific python versions such that I do not ever interact with my distribution's Python. This is cross platform so it works across mac, linux etc. Very easy workflow, isolated, safe, can get blown away and recreated in a heartbeat.

Sounds like something https://www.gnu.org/software/stow/ could help with.

You know, at this point in the complexity story, you're literally at (or beyond) the level of Nix complexity which is the very solution that everyone who engages with this level of tooling seems to be trying to avoid, and since Nix solves this problem already definitively without having to jump through all these hoops, why don't Python projects just use Nix? Then they could all be colocated on the same machine and all be accessible from the same PATH and all have their specific dependencies none of which would ever collide with each other!

Like, you're LITERALLY making a FANTASTIC argument for Nix usage in the Python ecosystem, here. In fact I'm going to bookmark this conversation now because of how ridiculously complicated your answer is compared to just using Nix.

Here's the Nix whitepaper. It's 14 pages or so. Read it on your next lunch break.

https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf