fix(python): if already in an active virtual environment, use it (do not force/assume ".venv")

[alexander-beedie]

With all the bytecode introspection going on recently I've been switching between 3.9 and 3.11 Python venvs a lot, and noticed that we don't account for the possibility of being in a non-default venv in the Makefile; while in my .venv_39 environment I ran make requirements and realised that it was updating packages in the default .venv directory instead.

This PR makes a small update to the Makefile definition such that if we are already in a venv we will use it, otherwise we continue to default to the standard .venv.

[stinodego]

I'm not sure this will work as intended. It will still require a .venv folder on your disk, right?

[alexander-beedie]

I'm not sure this will work as intended. It will still require a .venv folder on your disk, right?

Don't think so? The only behaviour change should be if you are already in a venv when you run make (which means you must have created one), in which case it sets VENV (and therefore also VENV_BIN) accordingly. Otherwise it should behave the same as before (creating .venv it if it doesn't exist, and using it if it does) 🤔

Logic is:

• Not in a virtual env; runs as normal, using .venv (creating if necessary).
• In a venv and it's the default .venv; runs as normal, doesn't create anything new.
• In a venv and its not the default.venv; sets VENV & VENV_BIN to the active venv, ensuring any subsequent commands are correctly targeted at the active dir (and doesn't create anything new).

[cjackal]

Looks to me like we still create a clean .venv if in a venv and .venv does not exist. And that .venv's python symlinks to original venv's python.

[alexander-beedie]

Hmm, does the right thing if .venv exists; I'll move it out of the way and see what happens otherwise; about to go to sleep, so will have to wait for a day or two. In the meantime if anyone can spot a suitable improvement, please go ahead ;)

[stinodego]

Basically, I think what you're trying to do is not supported by design. The Makefile is intended to work with .venv regardless of your active environment.

At some point, I played with the idea of having the Makefile be independent of the specific environment (basically remove the .venv requirement and leave it up to the user to create their own venv). But in the end, I don't think that's an improvement for most users. It would solve your issues in this case, though.

I think you're stuck with typing / hotkeying the actual commands for now instead of using make for your alternate environments. Unless you come up with a genius idea (wouldn't be the first time 😄 ).

[alexander-beedie]

Hmmm... ok, will stick this in Draft and poke at it some more 🤣

[alexander-beedie]

Will close out to get rid of PR clutter until I find the motivation to make this work...🤣