If you don't want to rely on the system or brew-installed Pythons for all your scripts, you might want to manage multiple Python installations with asdf-vm. --

If you don't want to rely on the system or brew-installed Pythons for all your scripts, you might want to manage multiple Python installations with asdf-vm. --- Disclaimer before I continue with my own suggestions: I have made small code contributions to pip and pip-tools, and maintain a Zsh frontend to pip-tools+venv, called zpy. --- Suggestions: - each folder of code maps to its own default venv, and may map to more venvs for different Python runtimes - each folder of code has a requirements.in file with top-level dependencies, and a requirements.txt as a lock file - you can either add a shebang line for your script which explicitly invokes the venv's Python and link that file into ~/.local/bin/, or instead create an external launcher script in ~/.local/bin/. --- Here's an example of how that might be done using zpy functions: $ mkdir simple-scripts $ cd simple-scripts $ envin # or in subcommand form: zpy envin ==> creating -> ~/.local/share/venvs/280…/venv :: ~/Code/simple-scripts $ pipacs httpx ==> appending -> requirements.in :: ~/Code/simple-scripts httpx ==> compiling requirements.in -> requirements.txt :: ~/Code/simple-scripts anyio==3.6.2 # via httpcore certifi==2022.12.7 # via httpcore, httpx h11==0.14.0 # via httpcore httpcore==0.16.3 # via httpx httpx==0.23.3 # via -r requirements.in idna==3.4 # via anyio, rfc3986 rfc3986==1.5.0 # via httpx sniffio==1.3.0 # via anyio, httpcore, httpx ==> syncing requirements.txt -> env :: ~/Code/simple-scripts $ print -rl -- 'from httpx import get' 'print(get("https://ifconfig.co/json").json())' >do_it.py $ vpyshebang do_it.py # or: zpy vpyshebang do_it.py $ ln -s $PWD/do_it.py ~/.local/bin/do_it If a Python runtime update breaks your venvs, you can probably fix things up using zpy's pipup function.