custom added envs have a Remove option under configure. auto detected ones dont. this seems inconsistent.
You can't add auto-detected environments, so it seems logical that you can't remove them, either. Assuming you could do so, what you would expect the behavior to be next time you start VS? Conceptually, since they're auto-detected, and the artifacts that they're detected from are still there, they would just reappear (in fact, since we scan for environments constantly, and not just on VS startup, they would reappear immediately as soon as you delete them).
valid point. i supposed a greyed out env that denotes PTVS auto-detected an env, but understands that i told PTVS to forget it. there could be an option to rehydrate it. basically i have 10 diff environments and i dont want them necessarily auto detected & analysis started & ... & ... ; this isn't high pri request by any means. i was just quite confused that there was no "Remove" option compared to other env's.
We don't start analysis until you actually start using that environment (e.g. by selecting it as a default environment for some project).
Sorry, but this is annoying to have environment you don't want to use. I suppose there could be another logic about working with environments. Unused environments are rather disturbing and crowding the env pane. You shouldn't derive workflow logic from the logic of existing software solution. Couldn't you reconsider this subject, please?
Anyway, PTVS is great work. Thank you -:)
We'd have to add new logic, UI, and settings in order to be able to hide environments from all the lists where they may appear. Our stats show that most people only have one or two environments though, so it'll struggle to dislodge some of the more valuable features we have in mind.
Also, if you genuinely don't want to use the environment, why not uninstall it?
Also, if you genuinely don't want to use the environment, why not uninstall it?
In my case, that is what I actually did. Now, I have a not removable environment, greyed out with invalid path entries. The underlying distribution is WinPython and the uninstalled version is also not longer registered. So, something seems to be wrong with the environment detection.
Was it automatically detected or did you manually configure it?
If the latter, you can remove it through the "Configure" section in the environments window.
If it was automatically detected, uninstalling it clearly did not clean up the registry correctly. If you can tell me which version it was I can help you find the keys you need to clean up manually.
registry
Thank you. I was quite sure about this, but with your remark in mind, I actually found some surviving remnants there. Now, the dialog is clean.
Hi, it seems a bug now. It auto detects a python 2.7 which install by canopy. But after I uninstall canopy, I can't remove this environment now. In Tools--Options--Python Tools--Environment Options--The Remove Environment button is grey, even start in admin mode. Now I get a useless python 2.7 which I can not delete. How to solve this plz ? :(
It's certainly a bug, but it's a problem with Canopy (they should have deleted their registry entries).
You'll need to manually edit your registry to clean up after them. You'll find one of HKEY_CURRENT_USER\Software\Python\PythonCore\2.7, HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.7 or HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\PythonCore\2.7 exists with paths to where Canopy used to be installed. If it is truly removed, you can delete the entire 2.7 key to clean up. Then we will stop showing the entry.
@DinoV Maybe we should check whether the path exists when we detect from the registry and just ignore invalid paths? I think that may hide more problems than it helps though...
Problem solved! Thanks so much!
The automatically detected Python environments cannot be configured at all (including deleted).
I can live with not being able to change paths manually or delete environments (why do you have it otherwise installed on your system?), but it would be nice to be able to change the name of the environment. I use 6 different Python environments making a "Python ..." named environment ambiguous.
(Currently, I configured everything myself by re-adding and re-naming environments. I do not use the automatically detected ones.)
With our latest version in VS 2017, you can go to the registry keys and add "DisplayName" values to change the name (have a look at Python 3.6's key for an example).
Adding our own layer on top of this is also possible and would obviously be useful, and once we've added a parallel information store about environments then it becomes much easier to hide them without corrupting the registry.
Ok then I'll wait for the Visual Studio 2017 release (not the RC version) to try this out (Currently, I am still using Visual Studio 2015 + PTVS).
I deleted some Python versions like Anaconda 4.1.1 from my system. PTVS in 2015, greyed out the "Open interactive window" button of these Python Environments, since the exe's are clearly not present anymore. (I don't know why PTVS doesn't just delete them instead of listing them.) I was able to delete some of them via the Options menu, but still one non-existing Python Environment with non-existing paths remained and could not be deleted since the delete button was disabled.
But since, I am migrating all my non-C++ stuff slowly to VS 2017, I removed PTVS 2015 and went on with PTVS integrated in VS 2017. Here, there is a similar problem. I have two Python Environments: Anaconda 4.1.1 and Python 3.5 which both point to a non-existing C:\Users\Matthias\Anaconda3 directory.
I checked my environment variables. I have no PYTHONPATH and PATH does not contain a path to non-existing Python distributions. I checked the registry and did not find any remainings of an old Python distribution.
Any ideas for dealing with these non-existing (anymore) Python distributions?
You can delete detected environments by removing them from
HKEY_CURRENT_USER\SOFTWARE\Python
Thanks @yorek !!
I was only looking in HKEY_LOCAL_MACHINE which contains new Anaconda distributions
We're closing old issues with no recent activity. If this is still important, please open a new issue.
Most helpful comment
It's certainly a bug, but it's a problem with Canopy (they should have deleted their registry entries).
You'll need to manually edit your registry to clean up after them. You'll find one of
HKEY_CURRENT_USER\Software\Python\PythonCore\2.7,HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.7orHKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\PythonCore\2.7exists with paths to where Canopy used to be installed. If it is truly removed, you can delete the entire2.7key to clean up. Then we will stop showing the entry.@DinoV Maybe we should check whether the path exists when we detect from the registry and just ignore invalid paths? I think that may hide more problems than it helps though...