Trouble inheriting project virtualenv values in Wing OS Command
I am running Wing 7.1.3.2 under Windows 10.
I am writing an app which uses flask. I installed virtualenv because it is recommended in the Flask docs.
I believe that followed your How-To and created the project using your Flask template. I then configured my project's Python Executable to the copy of python in my virtualenv directory.
When I am open my project, and I run the app using Wing's main "Start or continue debugging" button, everything works as expected, ie it uses my virtualenv.
But if I create a Wing OS Command, and leave it to default all of the Environment properties to my project settings, it is not using the virtualenv ... ie. my app cannot import from flask, as it is only installed in the virtualenv at this stage.
And in the Python Shell tool, I can see that it is not using the project's virtualenv either, ie. sys.executable points to the standard Python3 location.
is this expected? Can I use the Wing OS Command facility inherit my project's virtualenv? Should the Wing Python Shell tool inherit it's Python environment from the active project.
I don't know if it is relevant, but I am not writing a full flask app ... ie. I am only using its WSIG test server, so that I can control my app via html, when it is running on a headless device. So I am starting flask running manually, from inside of my app. Should I have used your Flask template? ... What does it do?
thanks
Comments
This might be a bug fixed in more recent versions of Wing. Could you please try 7.2.2.4 by downloading 7.2.2 from our website and then doing Check for Updates in the Help menu?
I upgraded to 7.2.2.0 and then to 7.2.2.4
It has not resolved the problem. Same problem with the OS Command facility, and the Python Shell tool.
OK, thanks for checking that. Using the Flask project template sets up a few things, mainly turning on child process debugging so auto-reload can be used, but should not be relevant to this. And yes, the venv should be used in OS Commands and Python Shell as well. One thing to check -- does restarting the Python Shell solve that part of it? By default it should auto-restart when switching projects, but this may be disabled and could explain using the wrong env. But in that case the status line at the top of the tool should be red and it should state it needs restart for env. I'm going to set this up here just to make sure it works and will get back to you.
It does use the venv for me in the Python Shell and OS Commands if I execute a Python file, whether I set Python Executable to Command Line and use the sys.executable or Activated Env and use the activate command. What are you executing in OS Commands? It sets things up differently if you're executing a Python file vs. the other command types, so this info may point me at the problem.
Restarting the shell does not fix things.
Command is just this ... python xxxxx.py
I closed Wing, and then restarted it ... I see your Project Open Read-Only dbox? I did have three version of Wing running earlier today ... three separate projects ... I was referring to 2 of them, and updating just one.
I closed Wing and rebooted after doing the Wing upgrade. I only opened 1 project when retesting in 7.2.2.4 .... I then closed the project and closed Wing. I don't know why it now thinks that my project is locked.