> I got tired of doing this for every project:
Then don't. All the activate script is really doing is setting a few environment variables. You can just specify the path to the venv's Python directly. Or use any number of other existing management tools. (Many of them do more sophisticated management than this. For example, permanently setting up the PATH so that `python` finds a shim executable that considers the CWD and finds the corresponding venv by whatever policy.)
> And the "just put it in a script" idea is misleading. Activation only sticks if it runs in your current shell. If you run a script, it runs in a subshell, so your terminal never actually gets activated.
So put it in an alias (like how your approach works), or source the script.
By the way, you can avoid the overhead of bootstrapping pip using the `--without-pip` option for `venv`, and then use an external copy of pip with `--python`. There are drawbacks to this, but it's generally better if you aren't going to run pip many times per venv and don't have to deal with EOL Python installs. I describe this incidentally in https://zahlman.github.io/posts/2025/01/07/python-packaging-....
> Also, if you have conda installed, python3 might point to conda's Python. That can create confusing venvs. This tool uses /usr/bin/python3 by default to avoid surprises.
That's a system-level config issue that the minority of Conda users should presumably already be aware of, if they really need to create both Python venvs and Conda environments.
