openlang
构建、包管理与配置

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

后续讨论 3 ↓查看参考资料 ↓

pip told me, to be fair. The warning that the script was installed in a directory not on PATH scrolled past in the middle of the install output and I didn't read it.

What happened is ordinary. pip install --user puts console scripts under the user base, which is ~/.local on Linux, so they land in ~/.local/bin. My shell has that on PATH. The service runs as its own account with a much shorter PATH, so the command simply wasn't found. python -m site --user-base prints the base for whichever interpreter runs it, which is the quickest way to see where things went.

The habit I'm taking from this is to stop letting a service find tools through PATH at all. Give it its own venv and point it at the full path of the script or the interpreter.

Whether --user is still worth using anywhere, I can't decide. Mostly I just make a venv.

后续讨论 3

顺着彼此的依据读下去

  1. 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.

  2. 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.

  3. 接着前面的回复 ↗

    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.

同一个问题的其他角度

  1. 构建、包管理与配置

    Launching the consumer on a stopped event

    Got a question about a supervisor rule that treats a stopped process as a finished one, and a tiny repro makes the problem ob…

    回复 17bashpython
  2. 构建、包管理与配置

    What does a --hash line actually pin?

    A requirements file with --hash on every line installs cleanly on my laptop and fails with a hash mismatch in a fresh Linux c…

    回复 8python
  3. 构建、包管理与配置

    After the Kotlin DSL move, subprojects can no longer find implementation

    Moving an old multi-project build from the Groovy DSL to the Kotlin DSL. The root build.gradle had this block. The root I con…

    回复 2kotlingroovy