Longer term, this functionality could be built into the py launcher (which at least for Windows users, is pretty much the definitive way to run Python) or even into the python executable itself - although that’s unlikely, given the SC’s preference for keeping packaging out of the core.
You can do that now. Just run pip in a subprocess. The problem is that a naive implementation installs the dependency in your main environment, which is generally not what people want here. You could run pip install --target to put the dependencies in a separate directory, modify sys.pathj, and delete the temporary directory on exit.
Edit: Actually, such a library function would make a perfectly reasonable consumer for PEP 722/723. So go ahead and write one if you think it’s a good approach - the PEPs will let you concentrate on implementing the infrastructure to make a list of dependencies available at runtime, without needing to design a data format or parse the dependencies out of your arguments.
The point is, this is available with no need for a standard. Although you could certainly write a function that read the script source and extracted PEP 722/723 metadata from it, meaning you get the best of both worlds - your preferred runtime functionality, and compatibility with runners for people who prefer them.
I could add it to the PEP 722 rejected ideas section. I probably should have, as this has been asked before, but honestly that section is so long already that I simply missed it. @ofek can add it to PEP 723 if he feels it’s worth it. If we come up with a combined PEP, I’ll try to remember to add it - there’s going to be a lot to do on the “rejected ideas” section for a merged PEP though, so no promises!