[mbreese]

I use venv's to keep library installs out of the global space. My python scripts won't run without those libraries, so running from the project root is pretty much required. I don't use the variables set by activating the venv, so that's not a real concern.

I've done this for years to keep my individual projects separate and not changing activations when switching directories. I also make sure to only call `venv/bin/pip` or `venv/bin/python3` when I'm directly calling pip or python. So, yes -- you have to be in the root project directory for this to work, but for me, that's a useful tradeoff. Even when running code from within a docker container, I still use this method, so I make sure that I'm executing from the proper work directory.

If I think that I need to run a program (without arguments), I'll have a short shell wrapper that is essentially:

    #!/bin/bash
    cd $(dirname $0)
    venv/bin/python3 myscript.py

As far as running a program that's managed by venv/pip, symlinks are essentially what I do. I'll create a new venv for each program, install it in that venv, and then symlink from venv/bin/program to $HOME/.local/bin/. It works very well when you're installing a pip managed program.

[hebelehubele]

I also use the trick to insert new lookup paths.

  project_root = os.path.dirname(os.path.abspath(__file__))
  sys.path.insert(0, project_root)