-
-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vf ls: Add --details to show virtual environment Python versions #190
Conversation
I'm not sure whether I'm totally satisfied with this yet, but I'm happy enough with it that I'd like to get feedback. Any thoughts on this feature, particularly regarding how it is implemented? (cc: @matan129 @cycomanic @airwoodix @cecep2 @gechr @mjstevens777) |
a00d38a
to
573206e
Compare
573206e
to
b12b35a
Compare
In addition to this pull request, I submitted another related PR (#191) containing a new |
The __vfsupport_get_default_python function's preference for $VIRTUALFISH_PYTHON_EXEC was fine for uninstalling VirtualFish and adding/removing plugins, but it was ill-suited for other uses where $VIRTUALFISH_DEFAULT_PYTHON was more appropriate, such as determining whether an environment's Python interpreter version is outdated. This changes the default priority to $VIRTUALFISH_DEFAULT_PYTHON (if defined) while preserving the previous behavior if the --exec flag is passed.
Instead of duplicating this logic in multiple places, use the __vfsupport_get_default_python function when trying to determine what the default Python interpreter should be.
Given a path to a Python interpreter, run `python -V` to ensure it isn't broken. Adding the --pip flag will run `python -m pip -V` to also ensure that Pip functions correctly.
Use the new __vfsupport_check_python function to ensure the detected path to Python interpreter is actually functional.
Also detect whether environments are in working order, and if so, whether the default Python version is more up-to-date than an environment's version.
b12b35a
to
ba2daa9
Compare
After refactoring and making some refinements, I'm pleased with this new implementation. The previous iteration was faster but did not detect environments with broken Pip executables, whereas the new function properly detects broken Pip situations at the expense of list speed. A worthy trade-off, in my estimation. |
Problem
At present, the only way to understand the state of one's virtual environments is to manually activate and inspect each one. There isn't an easy way to answer the following questions about virtual environments:
Solution
--details
option tovf ls
to show an additional column containing virtual environments' Python versions.