Hi guys, I’m trying to execute my application code after reinstalling Python on my machine, but when I execute the code, I get this message “ImportError: cannot import name ‘Flask’ from ‘flask’ (unknown location)”. I’ve tried uninstalling and reloading flask, but I’m still having issues. Could someone please help me get over this attack? it’s scaring me.
Most likely, Flask is not installed in the same Python install or virtual environment as your application is running in. If you activate the virtual environment/etc. for your application, then type
python -m pip install flask, and then run your application with
python yourapplicationstartscript.py or
python -m yourapplication (as appropriate) it should work. If you still can’t figure it out, run
python -c "import sys; print(sys.executable)" to get the path to the Python you’re using for
python -m pip, while running
import sys; print(sys.executable) inside your application will show you the Python interepreter used to run it. If those aren’t the same, that’s the problem. If they are, flask is installed and it still doesn’t work, then likely something is wrong with the install, your
$PATH is messed up or something else is going on.
Best of luck!
Just to clarify a bit, the purpose of using pip as:
python -m pip install flask
is to ensure that pip is installing in the same setup as the python
you’re running. (Adjust “python” to match how you’re invoking python to
run your app.)
When there are multiple pythons installed or different python
environments, this approach applies pip to the same environment as your
“current” python. So if you install flask this way, your current Python
should find it.
Cameron Simpson firstname.lastname@example.org
Some people, when confronted with a problem, think “I know, I’ll use venvs.” Now they have two problems.
- with apologies to Jamie Zawinski
I understand that venvs are useful if you need to run multiple versions of a library within a single version of Python. But I’ve never understood the purpose of venvs when you are merely installing the same, single, version of a library over and over again.
And I certainly don’t understand why we push beginners, who are having trouble installing libraries, into using venvs. That’s just one additional level of complexity to go wrong.
thanks sir, checking out what you just showed me, the env is executiong from different drive directory as the application directory.
BlockquoteC:\Users\KOBBY\AppData\Local\Programs\Python\Python39\python.exe: can’t open file ‘F:\python\WebApp-master\yourapplicationstartscript.py’: [Errno 2] No such file or d
i think my path is messed! Do i have to uninstall and reinstall python again? what do i do
You broke your application by reinstalling Python. Why do you think breaking it again will fix anything? As @steven.daprano recently wrote on this forum “Re-installing Python is superstition”
- In a terminal (CMD) window go to F:\python\WebApp-master (
cd F:\python\WebApp-master). If this doesn’t exist, then where does the webapp “live”?
- If the path exists, check if you find a source
yourapplicationstartscript.py. If it doesn’t then why is python looking for it?
- If it exists, look for the virtual environment. It is usually in a subdirectory called
venv, but the subdirectory may have a different name. You recognize it from subdirectories
Found it? Activate it by typing
<venv>\Scripts\activate.bat, where you replace
<venv> by the name of the subdirectory. Start the script (
py yourapplicationstartscript.py or
python yourapplicationstartscript.py). I expect this to fail, but how it fails is interesting.
Just to be clear, I wasn’t recommending the user create and use a new venv, but rather merely mentioning that if they are already using one for their application, they need to activate it first.
As a sidenote, I come from the scientific Python ecosystem, which largely uses conda and typically has large, binary and potentially conflicting dependency stacks, and has much less background in package and dependency management but often greater needs for different sets of dependencies, and greater vulnerability to issues caused by mixing channels and mixing pip and conda, if users are not careful. In that world, use of clean, isolated non-
base conda environments either solves or makes it relatively easy to solve a huge fraction, if not the majority of issues users, especially non-experts face.
On the other hand, for application deployment (e.g. with Spyder), we’ve moved away from using Anaconda as the application runtime environment (in addition to the working envs for the user’s code) to standalone installers for Windows and macOS (unfortunately, no common standard exists on Linux, so we still rely on conda there), since it was all too common for users to use the Spyder environment as their working env and install, update or remove packages that could break Spyder itself.
But I digress…