First time here? Check out the FAQ!
1

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

BarryM's avatar
25
BarryM
asked 2020-04-22 08:23:55 -0500
Wingware Support's avatar
4k
Wingware Support
updated 2020-04-27 07:52:18 -0500
edit flag offensive 0 remove flag close merge delete

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?

Wingware Support's avatar Wingware Support (2020-04-22 09:34:54 -0500) edit

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.

BarryM's avatar BarryM (2020-04-22 10:02:09 -0500) edit

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.

Wingware Support's avatar Wingware Support (2020-04-22 10:07:52 -0500) edit

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.

Wingware Support's avatar Wingware Support (2020-04-22 10:16:39 -0500) edit

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.

BarryM's avatar BarryM (2020-04-22 10:25:09 -0500) edit
add a comment see more comments

1 Answer

0

From further discussion by email the problem was narrowed down to two things:

(1) Command Line style OS Commands do not activate the virtualenv, in part because doing so could break some command lines. For example, if you use Command Line 'python3.8 myscript.py' you may not want the venv activated. We should probably add a configuration option for these to activate the venv, so we are treating this part as feature request. The work-around is to use Python File style OS Commands, or the Execute* items in the Debug menu. That will activate the project's virtualenv. Named Entry Point style OS Commands can also be used to activate a particular venv or no venv for a Python file.

(2) The virtualenv was activated correctly in the Python Shell but inspecting sys.executable was confusing because Debug/Execute > Debug Child Processes in Project Properties was enabled. When that is on, Wing replaces sys.executable so that child processes can be debugged so at quick glance it appears wrong because it's not set to the virtualenv's Python. However, the virtualenv is activated as it should be.

Wingware Support's avatar
4k
Wingware Support
answered 2020-04-23 10:37:24 -0500
edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer