Using wing pro with pyscaffold
I use pyscaffold to create all my projects and conda to manage the virtual environments. Everything just works in all IDEs (or it has to date). In Wing 7.2 the package imports all show errors, and pytest will not run (it fails with cannot read any output from test runner). The correct environment is active and package modules all run, although the editor shows imports as invalid (even though everything works). Tried under linux and windows. Any ideas?
Is Wing using the right Python or venv? What is the Python Executable in Project Properties set to? Also, you can see the effective Python Path, which would affect whether Wing finds modules in imports, in the Source > Show Python Environment dialog.
Yes I'm using the correct venv, and I have project properties set to activate it with the correct command. The environment is definitely active and all modules are found, but pytest just does not complete successfully. I have tried this on windows and linux. It is easy to reproduce. Just try running pytest
What version of pytest is it? Also is it failing in the Testing tool or in the debugger with code started outside of that tool?
I've not been able to reproduce this yet, so having some more info and/or a test case would be useful. What _might_ be relevant is that Wing 7.2 detects when Python is Anaconda and calls 'conda activate base' to avoid environment bugs seen before we did this. This works around Anaconda's assumption that you're using conda envs (with 'conda activate'). When that isn't used, Anaconda does not set up PATH right so loading some DLLs fails. Activating base does work using virtualenv instead (as opposed to conda envs), but perhaps there's an issue with this. One idea is to try both setting Python Executable to Command Line and entering the virtualenv's Python, and also setting it to Activated Env and entering the activate command instead, in case one or the other of those is not subject to any problem that may exist ... (more)
This is probably due to a bug in Wing <= 18.104.22.168, when Python Executable is set to Activated Env. Finding the value of sys.executable and using that with the Command Line option for Python Executable instead is a work-around. We're working on a fix.