> It feels like you're telling me that I'm holding my phone wrong.

I'm sorry you feel that way.

Ultimately, it is your code and you can do with it whatever you like.

...until your code becomes company code or open sourced. Then your way becomes a hinder to other developers.

> I don't like sourcing things into my environment. I've worked this way for years. I think the idea of 'activating' and 'deactivating' an environment is an anti-pattern.

I completely agree with you. The whole concept of a venv is great! But the concept of needing to source an activation script is... just... completely foreign to me. It took me months to understand that's the way it was intended to work, and more years to stop fighting it.

> I sometimes will have to run multiple programs (that have their own venvs) and pipe data between them.

Me too! I pipe data around all the time because it's amazingly fast and amazingly awesome to just hook up a pipeline. It can be done with venvs, too. Consider this:

    #!/usr/bin/env bash
    set -euo pipefail
    jq '.' < <(source venv1/bin/activate; ./script1) > >(source venv2/bin/activate; ./script2)

Here, script1 (which requires the first venv) might produce some JSON stuff to be processed by `jq`, then pipe that to script2 (which requires the second venv).

I'm curious how you do it though.