Pex has long supported (since 2010!) an immediate hermetic run mode for tools like so:

:; pex cowsay -ccowsay -- -tMoo!
  ____
| Moo! |
  ====
    \
     \
       ^__^
       (oo)\_______
       (__)\       )\/\
           ||----w |
           ||     ||

This is akin to pipx run:

:; pipx run cowsay -tMoo!
  ____
| Moo! |
  ====
    \
     \
       ^__^
       (oo)\_______
       (__)\       )\/\
           ||----w |
           ||     ||

And uvx:

:; uvx cowsay -tMoo!
  ____
| Moo! |
  ====
    \
     \
       ^__^
       (oo)\_______
       (__)\       )\/\
           ||----w |
           ||     ||

Pex has two disadvantages in use compared to pipx run and uvx:

1. You must name the entry point, even when it matches the name of the project supplying the entry point - which is common.
2. The PEX environment created to run the tool is ephemeral - it uses a temp directory that is destroyed; so subsequent runs are not as fast as you'd hope since they must re-create the PEX and re-bootstrap.

A new pex3 run command can fix both of these issues for more convenient ad-hoc tool use. In addition, pex3 run can support the proposal in https://discuss.python.org/t/pre-pep-add-ability-to-install-a-package-with-reproducible-dependencies by @CarliJoy since it aligns so well with Pex goals of hermeticity and reproducibility. Towards that end, I've published version 0.32.0 of dev-cmd which embeds a pylock.toml in its sdist at the top level and a dev_cmd-0.32.0.dist-info/pylock/pylock.toml as per the spec proposal. I'd like to have pex3 run dev-cmd --locked ... look for and use this metadata to create a tool environment known-matching with the environment dev-cmd was tested against when it was released at 0.32.0. There's alot of kerfuffle in the PyPA discourse thread(s) but it all makes perfect sense to me. Applications (wheel console script entry points are these!) are better served with lock files. Full stop!