What does vf check when it decides an env is "broken" ?

I have searched the issues (including closed ones) and believe that this is not a duplicate.
If related to a plugin, I prefixed the issue title with the name of the plugin.

Issue

hi there, long time user, was noticing this fancy "broken" descriptor in vf --ls and was curious what it means/what it checks? There doesn't seem to be any mention of what triggers vf as detecting a venv as "broken" and/or what it means for "upgrade" to fix them.

after a bit of troubleshooting, it looks like vf checks the status of python -m pip & throws away the output. I had a few venv's that i had created with --no-pip and that was the issue.

One possibility would be to change this line

virtualfish/virtualfish/virtual.fish

Line 876 in 6988e4a

set -l test_py (fish -c "'$python_path' $pipflag -V" 2>/dev/null)

, instead piping to something in /tmp/, so the caller could dump it out on a nonzero return code.

Hey Andrew. An alternative approach would be to change the test to account for the use case in which --no-pip has been invoked. Can you think of other ways of detecting when the virtual environment has lost all motor function? 😉

No, but i'm not the right guy to ask because i'm not an expert on the edge cases of virtualenvs, i'm just a guy trying to keep projects isolated and know that venv's are the way to do it in python.

i mean, all i really wanted was to know what was meant by "broken" 🙃. After digging in to find out, i still only understand one way that it can be broken (my way), so i'm pretty sure i don't know what's the best way to document what it needs.

In the past, the most common way I encountered broken virtual environments was when Homebrew upgraded Python (without my explicit invocation, mind you). For that reason, I no longer use Homebrew Python, as documented in Homebrew Python Is Not For You.

On another note, I don't understand the motivation behind creating environments without Pip. Could you elaborate regarding why you use that flag?

In any case, if you would like to propose a PR to address the /dev/null'ed error output, that might be (as you suggested) the best way to address the specific issue you experienced.