The --user scripts dir was never on the service PATH

Where did pip put the script, and should the service be looking it up by name at all? Those two, in that order.

python -m site --user-base answers the first, as long as you run it as the same user and with the same interpreter the service uses. Run from your own shell it describes your account, which is a different user base. Once you have the base, the scripts sit in its bin directory.

Then the second, and I'd settle it before touching PATH. A unit that names /srv/app/.venv/bin/tool keeps working whatever PATH the service manager hands it, because the script's shebang points at the venv interpreter. Adding ~/.local/bin to the service's PATH works too, but then the service depends on one account's home directory.

Leave --no-warn-script-location out of it. Next time that warning is the line to look for.

Your login shell was quietly supplying part of the setup, a PATH with ~/.local/bin in it, and in your own sessions it happened to be the right one. Most wrong-interpreter mix-ups start in the same place, with whichever pip the shell finds first.

A full path in the unit settles which program runs. Anything else the tool picked up from your login environment, variables included, is still worth listing before calling the service fixed.

ajp's first question has a dull answer. As the service user, python -m site --user-base gives that account's ~/.local, not mine.

The tool lives in a venv owned by the service now, and the unit points at /srv/app/.venv/bin/tool. Under env -i it starts fine with no PATH at all.