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.
am a bit confused by this "whether I set Python Executable to Command Line and use the sys.executable or Activated Env and use the activate command"
I am not doing any of that. ... I was presuming that you where handling all that due to the fact that my project configuration has showed you that I am using python.exe from inside a venv... correct?
Running from the "Start or continue debugging" button works auto-magically for me. I am assuming that the other two things should do the same ...
I'm not sure either. Could you please submit a bug report from the Help menu and include the error log? That may show us what is happening. In any case, you can break the project lock in the dialog that reports it.
Another thing to check in the Python Shell is whether the env checked under Use Environment in its Options menu is Project Properties. It can be set up to use a different env than the project, which might also explain that part of the problem.
Oh, are you saying you don't have Python Executable in Project Properties set? In that case, Wing is inheriting the env from where it was started. It's best to set Python Executable. I'll check if starting Wing in the activate env shows the problems you report.
I also tried activating the env on the command line and starting Wing from there into a project that has no Python Executable configuration and it correctly inherited the venv into debugger, OS Commands, and Python Shell. So I'm not sure what is going wrong. Hopefully the bug report and error log will show something.
"Oh, are you saying you don't have Python Executable in Project Properties set?"
No, I did not mean that. I do have it set in the project, but not in the OS Command, as I was assuming that it was getting this from the project.
OK. Thanks. Is late here, so going to bed.
In the morning I will delete the project, and the recreate with "use existing virtualenv" instead of the flask.template.
If the problem persists, I will find out how to get the error log file for you, and submit as a bug...OK?