Earlier quoted context omitted.
You can have your cake (use multiple venvs) and eat it (flexibility) too. `source venv/bin/activate` from your .sh files will cause `/usr/bin/env python3` to use the python3 located in your venv. Switching between venvs is easy too. just call `deactivate` when one venv is activated. It drops you out of the venv. You can then cleanly `source venv2/bin/activate`.
It feels like you're telling me that I'm holding my phone wrong. 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. But I also work on HPC clusters where all of the configuration about paths is handled by the environment. Because of this, I've learned the hard way that for my workflows, it's far too e…
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 venv2/bin/activate; ./script2)
I'm curious how you do it though.