I have to do a new course for University using python. A year or so ago I have installed Anaconda, but never really worked with it. Before starting I wanted to update everything, so I uninstalled my python and Anaconda version and reinstalled the newest version (I know I could have just updated everything).
I would like to work with VS2017, since this is the IDE I'm used to work with (coming from a c# background), however within the python environment window, my old versions are still visible, although with a strike-through font:
VS2017 has no option to remove the broken/uninstalled environments, but refers you to this website. In the bottom section there is a description to my solve my problem. Normally I don't really like to edit the registry, since I'm not know my way around this stuff, however this being directly from the learn.microsoft.com pages, I thought it was ok.
Problem only is, the changes didn't have any effect on my issue whatsoever.
(already did the obvious stuff like restarting VS2017 and Windows).
Additional Info
My problem is that I wanted to run the python script skeleton we got from the course to check if all the modules and python itself is working properly. However I always get a dll load failed error on some of the modules (matplotlib for example). Running the scripts on other IDEs (like Anaconda's integrated Spyder IDE) however works just fine, so I know the modules are good to go on my machine. I wanted to rule the above mentioned issue out as source of error before looking further.
Checking with Process Monitor (starting up VS with monitoring active, up to bringing up the Python environments list in it; then stopping monitoring and setting filters: Process name is devenv.exe, Path contains python, conda or ContinuumAnalytics (three separate filters)) shows that VS searches these locations for Python installation data:
Registry keys, under HKCU (the document fails to mention this) and HKLM:
\Software\Python and \Software\Wow6432Node\Python (which is seen as the former by 32-bit processes)
Files:
<user profile>\.conda directory
It also looks for conda.exe in a few locations
I don't have it, but if I did, it would be possible to see with procmon which command lines VS is invoking it with. Then you could e.g. do the same yourself and see what information VS gets from it.
If VS finds the entries that you list, something referring to what you see in the list must be under these locations somewhere.
To remove the entries, as I already mentioned,
First check if you have the corresponding product installed and uninstall it if you do. Entries under HKCU refer to products installed per-user so you'll have to run appwiz.cpl as yourself (or rather, as the same user that you run VS as) to see them.
If you really don't have it installed, do the usual manual cleansing procedure. Delete anything from the registry and disk that looks relevant (by name, location), including the above entries. At your own risk, of course. For VS to stop finding them, deleting the entries should be enough. You can also try to reinstall and uninstall the exact same version of software (which can be tricky to find) and hope it uninstalls correctly this time.
To correct python environment in Visual Studio that doesn't have a repair option, or to remove an invalid environment, use the following steps to modify the registry directly. Visual Studio automatically updates the Python Environments window when you make changes to the registry.
Run regedit.exe.
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Python. For IronPython, look
for IronPython instead.
Expand the node that matches the distribution, such as Python Core
for CPython or ContinuumAnalytics for Anaconda. For IronPython,
expand the version number node.
Inspect the values under the InstallPath node:
If the environment still exists on your computer, change the value of ExecutablePath to the correct location. Also correct the (Default) and WindowedExecutablePath values as necessary.
If the environment no longer exists on your computer and you want to remove it from the Python Environments window, delete the parent node of InstallPath, such as 3.6 in the image above.
Ref: Microsoft Doc - https://learn.microsoft.com/en-us/visualstudio/python/managing-python-environments-in-visual-studio?view=vs-2019#fix-or-delete-invalid-environments
Related
up until recently I have only worked with one version of Python and used virtual environments every now and then. Now, I am working with some libraries that require older version of Python. So, I am very confused. Could anyone please clear up some of my confusion?
How do I install multiple Python versions?
I initially had Python version 3.8.x but upgraded to 3.10.x last month. There is currently only that one version on my PC now.
I wanted to install one of the Python 3.8.x version and went to https://www.python.org/downloads/. It lists a lot of versions and subversions like 3.6, 3.7, 3.8 etc. etc. with 3.8.1, 3.8.2 till 3.8.13. Which one should I pick?
I actually went ahead with 3.8.12 and downloaded the Tarball on the page: https://www.python.org/downloads/release/python-3812/
I extracted the tarball (23.6MB) and it created a folder with a setup.py file.
Is Python 3.8.12 now installed? Clicking on the setup.py file simply flashes the terminal for a second.
I have a few more questions. Hopefully, they won't get me downvoted. I am just confused and couldn't find proper answers for them.
Why does Python have such heavy dependency on the exact versions of libraries and packages etc?
For example, this question
How can I run Mozilla TTS/Coqui TTS training with CUDA on a Windows system?. This seems very beginner unfriendly. Slightly mismatched package
version can prevent any program from running.
Do virtual environments copy all the files from the main Python installation to create a virtual environment and then install specific packages inside it? Isn't that a lot of wasted resources in duplication because almost all projects require there own virtual environment.
Your questions depend a bit on "all the other software". For example, as #leiyang indicated, the answer will be different if you use conda vs just pip on vanilla CPython (the standard Windows Python).
I'm also going to assume you're actually on Windows, because on Linux I would recommend looking at pyenv. There is a pyenv-win, which may be worth looking into, but I don't use it myself because it doesn't play as nice if you also want (mini)conda environments.
1. (a) How do I install multiple Python versions?
Simply download the various installers and install them in sensible locations. E.g. "C:\Program Files\Python39" for Python 3.9, or some other location where you're allowed to install software.
Don't have Python add itself to the PATH though, since that'll only find the last version to do so and can really confuse things.
Also, you probably want to use virtual environments consistently, as this ties a specific project very clearly to a specific Python version, avoiding future confusion or problems.
1. (b) "3.8.1, 3.8.2 till 3.8.13" which should I pick?
Always pick the latest 3.x.y, so if there's a 3.8.13 for Windows, but no 3.8.14, pick that. Check if the version is actually available for your operating system, sometimes there are later versions for one OS, but not for another.
The reason is that between a verion like 3.6 and 3.7, there may be major changes that change how Python works. Generally, there will be backwards compatibility, but some changes may break how some of your packages work. However, when going up a minor version, there won't be any such breaking changes, just fixes and additions that don't get in the way of what was already there. A change from 2.x to 3.x only happens if the language itself goes through a major change, and rarely happens (and perhaps never will again, depending on who you ask).
An exception to the "no minor version change problems" is of course if you run some script that very specifically relies on something that was broken in 3.8.6, but no fixed in 3.8.7+ (as an example). However, that's very bad coding, to rely on what's broken and not fixing it later, so only go along with that if you have no other recourse. Otherwise, just the latest minor version of any version you're after.
Also: make sure you pick the correct architecture. If there's no specific requirement, just pick 64-bit, but if your script needs to interact with other installed software at the binary level, it may require you to install 32-bit Python (and 32-bit packages as well). If you have no such requirement, 64-bit allows more memory access and has some other benefits on modern computers.
2. Why does Python have such heavy dependency on the exact versions of libraries and packages etc?
It's not just Python, this is true for many languages. It's just more visible to the end user for Python, because you run it as an interpreted language. It's only compiled at the very last moment, on the computer it's running on.
This has the advantage that the code can run on a variety of computers and operating systems, but the downside that you need the right environment where you're running it. For people who code in languages like C++, they have to deal with this problem when they're coding, but target a much smaller number of environments (although there's still runtimes to contend with, and DirectX versions, etc.). Other languages just roll everything up into the program that's being distributed, while a Python script by itself can be tiny. It's a design choice.
There are a lot of tools to help you automate the process though and well-written packages will make the process quite painless. If you feel Python is very shakey when it comes to this, that's probable to blame on the packages or scripts you're using, not really the language. The only fault of the language is that it makes it very easy for developers to make such a mess for you and make your life hard with getting specific requirements.
Look for alternatives, but if you can't avoid using a specific script or package, once you figure out how to install or use it, document it or better yet, automate it so you don't have to think about it again.
3. Do virtual environments copy all the files from the main Python installation to create a virtual environment and then install specific packages inside it? Isn't that a lot of wasted resources in duplication because almost all projects require there own virtual environment.
Not all of them, but quite a few of them. However, you still need the original installation to be present on the system. Also, you can't pick up a virtual environment and put it somewhere else, not even on the same PC without some careful changes (often better to just recreate it).
You're right that this is a bit wasteful - but this is a difficult choice.
Either Python would be even more complicated, having to manage many different version of packages in a single environment (Java developers will be able to tell you war stories about this, with their dependency management - or wax lyrically about it, once they get it themselves).
Or you get what we have: a bit wasteful, but in the end diskspace is a lot cheaper than your time. And unlike your time, diskspace is almost infinitely expandable.
You can share virtual environments between very similar projects though, but especially if you get your code from someone else, it's best to not have to worry and just give up a few dozen MB for the project. On the upside: you can just delete a virtual environment directory and that pretty much gets rid of the whole things. Some applications like PyCharm may remember that it was once there, but other than that, that's the virtual environment gone.
Just install them. You can have any number of Python installations side by side. Unless you need to have 2 different minor versions, for example 3.10.1 and 3.10.2, there is no need to do anything special. (And if you do need that then you don't need any advice.) Just set up separate shortcuts for each one.
Remember you have to install any 3rd-party libraries you need in each version. To do this, navigate to the Scripts folder in the version you want to do the install in, and run pip from that folder.
Python's 3rd-party libraries are open-source and come from projects that have release schedules that don't necessarily coincide with Python's. So they will not always have a version available that coincides with the latest version of Python.
Often you can get around this by downloading unofficial binaries from Christoph Gohlke's site. Google Python Gohlke.
Install Python using the windows executable installers from python.org. If the version is 3.x.y, use the highest y that has a windows executable installer. Unless your machine is very old, use the 64-bit versions. Do not have them add python to your PATH environment variable, but in only one of the installs have it install the python launcher py. That will help you in using multiple versions. See e.g. here.
Python itself does not. But some modules/libraries do. Especially those that are not purely written in Python but contain extensions written in C(++). The reason for this is that compiling programs on ms-windows can be a real PITA. Unlike UNIX-like operating systems with Linux, ms-windows doesn't come with development tools as standard. Nor does it have decent package management. Since the official Python installers are built with microsoft tools, you need to use those with C(++) extensions as well. Before 2015, you even had to use exactly the same version of the compiler that Python was built with. That is still a good idea, but no longer strictly necessary. So it is a signigicant amount of work for developers to release binary packages for each supported Python version. It is much easier for them to say "requires Python 3.x".
I am implementing an interface which allows Python to be loaded and used from a Windows C++ application. It should be able to use any Python registered in the Windows registry. This seems to work fine with e.g. Python 3.8 downloaded from www.python.org. However, with current Anaconda/Python 3.7 I am having problems. It looks like it expects a lot of directories to be present at PATH, and this knowledge seems to be hidden in a cryptic conda.bat file. Especially the folder C:\ProgramData\Anaconda\Library\bin seems critical, without this e.g. numpy won't load.
In short, assuming that I start just with the following info piece from registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\3.7\InstallPath]
#="C:\\ProgramData\\Anaconda3"
how should I prepare PATH and potentially other things so that the loaded Python DLL, from Anaconda or not, would be fully functional? For this particular Anaconda version I can add them by hand, but this seems not so sustainable.
I know that one solution is to select a check box during Anaconda install which will put the needed directories to the system PATH. However, this check box is not selected by default and is marked as "not recommended", so there is not much hope that our end users will actually check it.
I recently uninstalled and reinstalled python, and i have not been able to save one of my programs since.
When i hit ctrl+S, IDLE throws me a window saying I/O Error: Bad file descriptor. I can not even save my file!
As it turns out i don't think it has anything to do with the actual code. No matter what is in the program, it still throws this error when i try to save, unless there is no code whatsoever!
IF anyone knows why this error is occurring, please tell me or post an updated version of the code, any help is appreciated
I am using Windows 10, Python 3.7.3 64-bit [a couple days ago i uninstalled (just through windows settings) 32-bit and installed 64 from the python website]
I have experienced the same issue.
In my case the Windows 10 Defender was the root cause.
I added in Windows Defender Ransomware Protection the python.exe of my used IDE and the issue disappears.
In Windows, it is theorically possible to install 32 bits and 64 bits versions of Python side by side, and it should work with a genuine installation. But dragons are waiting around:
it is possible to have shortcuts pointing to a wrong location.
if the PATH has been changed to allow direct usage of the python, or pip command from the command line, risk is that you use the wrong tool
if any Python environment variable has been set, problems are almost guaranteed
Furthermore, Python can be installed either for the current user or for all users, which adds more possibilities for inconsistancies.
Once an installation is deemed broken, uninstalling one of the versions is generally useless on can even cause more problems. Long story short, if you have entered the world of inconsistancy, you must clean up everything.
My advice here is:
find where the Python versions were installed and note it
find if additional tools (py) have been installed and try to find which ones
uninstall every Python version
control that the installation paths are empty
search the environment and PATH for any Python related information and remove them
When everything looks good, reinstall from the installation wizard.
Hopefully it should work. If it does not I cannot help: despite being presented as an end user friendly system, Windows is a very feature rich and complex OS and trying to fully analyze a Windows system is beyond the capacity of most users, including most power users and sysadmins. At a point, the only possibility left is to reinstall the full OS and then cleanly install everything back... when it is possible...
When we uninstall any software sometimes we find some registry files in registry. Is it same to Python programming installation?
If you use the uninstaller to uninstall Python it should clean everything up. However if you're particularly paranoid about leftover registry entries, PEP 514 defines where Python creates registry entries. Note that Python doesn't necessarily need to make registry entries in the first place:
Python environments are not required to be registered unless they want to be automatically discoverable by external tools.
The system path however may still have the path to the previous python installation in it, as per this SO question here. Further searching reveals more useful information about removing Python.
Pythons installed under WinXP have dirs like DLLs, DOC, include, etc. but python (2.5) installed with cygwin is a bare python.exe. My motivation for asking is that 'things' under XP don't seem to be finding 'other things' under cygwin and vice versa, I want to start developing with Qt, I like shells, and I do not like MS; I thought if I got all the components under one roof, I could finally start to have scripts find executables which could find files and such. 1. Can I simply copy the contents of an XP installation into the cygwin tree? 2. Is the XP flavor of Python different from the cygwin flavor? (Same CPU, he pointed out, naively.) 3. Someone must work with a full-fledged (if snakes had feathers...) Python from within cygwin; how is it done?
Disclaimer 1: I have never compiled anything under XP or cygwin; had hoped not to have to go there, hence, python in the first place. Disclaimer 2: sorry if this is a ServerFault question, but they seemed to be system people over there and this is (in my case) a lowly desktop.
I use Python from within cygwin, but I don't use the version that cygwin gives you the option of installing as I don't have the control over version number used that I need (we use an older version at work). I have my python version installed via the windows installer (the xp version as you put it) and add the /cygdrive/c/Python2x directory to my PATH environment variable.
Well, in my windows environment I use active python and it, so far, works for me.
Just a little off the question, but...
Have you considered running Sun's VirtualBox with Fedora or Ubuntu inside of it? I'm assuming you have to / need to use windows because you still are, but don't like it. Then you would have python running inside a native linux desktop without any of the troubles you mentioned.
And if you want something that is really easy and portable, then just use Python on Windows, not mixed in with cygwin.
$0.02
This probably has little value, but... I found myself in this exact situation -- we use ActivePython2.5 in production (pure windows environment) and I was trying to do my development within cygwin and cygwin's Python...
After ripping out half of my hair, I have now switched over to Console2, gvim, iPython and ActivePython2.5.
I'm less than thrilled dealing with Windows tools (and their concomitant warts), but at least I'm not getting in my own way when it comes to development. For a while I found I was spending more time trying to get my tools to play nice than actually getting any work done.
Good luck on this one.
I accidentally stumbled on this - If I launch Cygwin from the Cygwin.bat file (which is present directly under the main folder), I get access to the Python version installed under Cygwin (i.e 2.6.8)
If I instead launch the Cygwin from bash.exe under bin directory (C:\Cygwin\bin\bash.exe for me), running "Python -V" shows that I have access to 2.7.3 version of Python (that was installed for Windows).
So, I guess you can do the same.