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.