We Keep Coding

Python not found

I'm working on a project in a python virtual environment, the project was started on a pc with python 3.8 installed and consequently python 3.8 was used in the virtual environment, or I had the need to continue the project on another pc, so I loaded all on GitHub, in the end I downloaded it to another PC with python 3.11 installed, the files are all there but when I try, inside the virtual environment, to open python by writing python or python3 in the terminal, it shows up this error: Python not found; Run with no arguments to install from the Microsoft Store or disable the link from Settings > Manage apps Run aliases. I then tried to see if it only showed up inside the virtual environment, but the same thing happens outside as well.
I tried to do various things among those suggested in other forums but they didn't work, the problem persists, I'm a bit lost, it's the first time this has happened to me.
Sorry to bother, maybe it's the simplest problem there is to solve but I don't know where to start
Trhanks

The problem is the different version of python on the two computers... the content of the pyvenv.cfg file must simply be changed which, when creating the virtual environment, is based on the installed version. Here you just need to change the path to reach the python.exe file installed on your computer and then change its version by inserting the correct one.

pip looking in wrong folder

My issue requires some backstory.
I was having some troubles with pip, so I reinstalled Python. After the reinstall pip began to work, but Pycharm, my IDE, could no longer find Python. When I reinstalled Python it created a new folder for itself (Python310), but Pycharm kept looking in the old folder (Python39). I couldn't figure out how to get Pycharm to look in the new folder. Even deleting and reinstalling it did nothing.
So, I renamed Python310 to Python39 and changed the PATH. Now Pycharm can find Python. But pip has developed a new and exciting error. When I try to use it I get the following message:
Fatal error in launcher: Unable to create process using '"C:\Users\user\AppData\Local\Programs\Python\Python310\python.exe" "C:\Users\user\AppData\Local\Programs\Python\Python39\Scripts\pip.exe" install numpy': The system cannot find the file specified.
If I read this correctly pip is still trying to look in Python310. Would you please tell me what I need to do to get pip to looking in the right place?

So, to start. You don't fix this by renaming the folder where the interpreter resides. Even if that worked, it's not a fix. The name will say one thing, but it's actual version, compatible libraries, and anything else tied to the version number would be incorrect.
If you take a close look at the error message from pip, it tells us what's wrong.
Fatal error in launcher: Unable to create process using '"C:\Users\user\AppData\Local\Programs\Python\Python310\python.exe" "C:\Users\user\AppData\Local\Programs\Python\Python39\Scripts\pip.exe" install numpy': The system cannot find the file specified.
You renamed the directory, so your IDE can find it, but pip and everything else using the Python interpreter is still configured to look in the Python39 directory to find it.
The problem you are having is that your IDE, PyCharm, needs to be configured for your project. You have to tell it where the Python interpreter is. The simple solution, you can rename your your Python folder back to it's original state, and add it to your project.
Press Ctrl+Alt+S to open the project Settings/Preferences and go to Project | Python Interpreter. Click the Add Interpreter link next to the list of the available interpreters.
Expand the list of the available interpreters and click the Show All link.
Select the target interpreter.
In your case, look for the one with this file path: "C:\Users\user\AppData\Local\Programs\Python\Python310\python.exe"
I would recommend going one step futher and create an interpreter in a virtual environment. Especially if you are interested in Python beyond a very casual hobby. They are unavoidable.
This link is a good source and can help you with this:
https://www.jetbrains.com/help/pycharm/configuring-python-interpreter.html#interpreter
There, you will find screenshots that follow the steps I listed above. There are also detailed instructions on how to create and add a new interpreter in a virtual environment. The relevant headings are as follows:
Configure a Python interpreter
Python interpreters in PyCharm
Setting an existing Python interpreter
Creating a new Python interpreter
The rest of the content is great as well, and may help answer questions you didn't know you had.

try to uninstall all of the existing python versions. and install it again. using any of application allow you to delete most of files, so to prevent error when re-install .

Option 1:
delete and reinstall again. and then when creating a project it should prompt you to pick a basic interpreter, choose python310 or whatever version you're using.
Option 2:
use a different IDE.

Why is python setup popping up when I start Pycharm and where is my python interpreter?

When I start Pycharm, this python setup menu pops up.
Python 3.7.4 is not even the version I'm using. Everything else works fine and I can just close it, but it is annoying.
There was a same question, and the answer was
You appear to be using the installer .exe as if it were the Python interpreter. Install Python to somewhere first, then use the python.exe in the bin directory inside that.
But I can't find where my bin directory is. My Python37-32 folder looks this.
How do I find my python interpreter?

Open some project -> File -> Settings -> Project: ... -> Project Interpreter -> Show All ... to view the list of available interpreters added to PyCharm.
Find and remove the interpreter which is pointing to Python distributive from the newly opened list.
At some point in past you added Python installer as a project interpreter in PyCharm so now when IDE tries to use this exe to run some background tasks (e.g. to get sys.path) installation wizard is triggered instead.
Correct python.exe to point PyCharm to is right on your screenshot

According to official python documentation.
The Python interpreter is usually installed as
/usr/local/bin/python3.8 on those machines where it is available;
putting /usr/local/bin in your Unix shell’s search path makes it
possible to start it by typing the command:
Since you are using Windows here, you are already in the location where the python interpreter resides. So look no further.
By the looks of the screenshots, I have a concern whether you have installed python correctly.
If you did not select the checkbox for Add Python 3.7 to PATH, the wizard expects you to do it manually which is why the error.
I would uninstall and reinstall Python and this time make sure to check that box. I am sure your error messages should go away.
Alternatively, if you're not in the disposition to uninstall. According to python docs here you can set the python variable to PATH variable and try.

IntelliJ + Python plugin: Python remote interpreter gets created without classpath, does not work

When I create a new remote Python interpreter, IntelliJ doesn't find any dependencies to my code and doesn't seem to index any libraries. Most of the code is red. I think I've pinpointed that to the "classpath" being completely empty, which is unlike some other Python SDKs that I have added (local ones). Some of the times I am able to get it to populate the classpath with paths pointing to the IntelliJ Caches directory by clicking around in the interface, but I most of the times it does not work and I cannot reproduce how to make it work. How do I make sure the classpath gets populated correctly?
I am using IntelliJ Ultimate version 2016.2.1. with the Python plugin version 2016.2.162.43. I am developing on a Vagrant virtual machine and I'm adding a Python remote interpreter that is inside a virtual environment (venv) inside the virtual machine. When I add the remote interpreter, I use:
On the SDKs tab - the + button.
Python SDK
Add Remote
I select the Vagrant option
Point it to my Vagrant project directory.
Point it to the python3.5 executable inside my virtualenv
Add the SDK
Then the classpath looks like this: https://www.dropbox.com/s/3xbzopb4y9bhn0u/Screenshot%202016-08-11%2017.19.43.png?dl=0 and IntelliJ doesn't recognize any libraries/builtins. For other SDKs, the classpath contains several entries with remote_sources, python_stubs or python-skeletons in the name and they work.

As a workaround, I copied every entry from the local python interpreter classpath to the remote one and everything seems to work
Edit:
Actually, I don't know what triggered it, but some days after I wrote this, I noticed that IDEA started downloading source files from the server. I went to the interpreter settings, and the classpath entries I had manually added were gone and replaced by "system/remote_resources" entries. I think this is how it's supposed to work, but unfortunately I don't why I didn't work from the start nor how to trigger the correct behavior, it just started working on its own.

While this issue is a bit older, I had the same issue today with IntelliJ IDEA 2021.2.
I was able to solve this by using Navigate -> Search Everywhere -> Type interpreter -> Select Rescan Available Python Modules and Packages.
This prompted downloading of the remote resources and indexing. Afterwards, the classpaths were filled in properly.

Install Python modules on Shared hosting virtualenv

Experimenting with using python in a virtualenv on my shared hosting account. Based on this dreamhost tutorial have installed pip and another module or two (echonest, remix), but trying to install numpy the long list of errors starts with non-existing path in 'numpy/distutils': 'site.cfg'
/bin/sh: svnversion: command not found.
The virtualenv instructions I read say, "make sure that your path gives preference to ~/local/bin to /usr/bin so that your "local" copy of Python runs, and that your scripts refer to that location."
Does that suggest to make a link somewhere that points calls to /usr/bin/ to ~/local/bin?
Is the solution to find the install package and edit the paths in it's setup.py file?

this is referring to the linux environment variable $PATH which lists the directories in which to look for executables for commands when you don't specify an absolute path. this will contain a list of comma separated paths eg:
/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
You just need to make sure that the /usr/local... stuff comes first (left) like this:
export PATH=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin

Are you sure you're running ~/local/bin/python when running setup.py?
One virtualenv-specific thing you can do is source ~/local/bin/activate, which automatically sets your virtualenv to take preference over everything else in your path. It only works until you log out of your terminal instance or run deactivate

I'm seeing confusion in the comments--- between "local" and "your virtualenv". And there is a parallel problem with $PATH. Is there just one path issue? No... there are two.
True, my own analogous efforts on a different shared-hosting account are ultimately crashing too, but I'm further along and I appear to have some things figured out. The confusion here partly comes about because there are two Dreamhost tutorials that are linked to in the question, but the authors of those two wiki chapters didn't make any effort to integrate the two.
And in the second tutorial on Python the mistake is made of introducing the discussion of the local directory in the virtualenv section though it's only really explained in the next section on building your own Python. And the discussion on building your own isn't complete regarding what to do about $PATH. You don't need to build your own Python or have a local directory just to use virtualenv.
It may even be detrimental. The language at this official virtualenv page should fill you with despair, as it shows no effort at clarity. I think that it means that mod_python and mod_wsgi, either of which you must be using for your Flask experiment, don't use any Python that you might come up with--- they use their own Python interpreter, the system's version. But virtualenv, the program, also puts a Python interpreter inside your virtual environment (the interpreter that you will use to do installs and also ultimately to run flask if you let it). The point of the warning from the virtualenv folks is that you can't run with two different interpreters in the same server process. They show you the workaround.
But I have digressed. The second, Python tutorial instructs about building your own local Python, in the directory /home/yourusername/local. A more complete, yet succinct discussion is to be found at Sugath Mudali's Blog.
Your virtualenv should occupy a second directory, which I'll call yourvirtenv. Alongside ~/local should be OK.
So, per Sugath Mudali's helpful instructions, you need to execute export PATH=/home/yourusername/local/bin:$PATH, which puts /home/yourusername/local/bin at the front of your $PATH, which you can confirm with "echo $PATH". Once you've done that, whenever you use "python" in your shell you'll be using the Python that you just installed, whose path you just put first.
Having done that, if you then cd into to your virtualenv source folder (somewhere in /home/youruserhame) and run "python virtualenv.py /home/youruserhame/yourvirtenv" it will create a directory ~/yourvirtenv, into which it will put a copy of the interpreter of your local Python. Generally it will not only be a distinct copy but it will differ even as to version from that of your system, which is at /usr/bin/ as /usr/bin/python ("usr" here is not you but is the oddly-named directory of the entire shared Linux machine to which no unprivileged user such as you has access, into which program binaries can be installed, by the privileged, for system-wide use).
Note that the Dreamhost Python wiki says "DreamHost has begun upgrading servers to Python 2.6.6 as of February 2012." Version 2.6 is adequate for virtualenv and practically everything else. So I would question the need to build your own Python in your case. (Note that Dreamhost even suggests that you should try to forget about it entirely.)
Anyway, on to the second PATH deal, as limasxgoesto0 noted, once you run virtualenv.py and have thus created myvirtenv, if you're still in the /home/myusername user-root directory you run source myvirtenv/bin/source. That puts /home/myusername/myvirtenv/bin at the front of the path--- until you later simply run "deactivate" (no source in front of it). That is all that activate does.
Now, when you return days later and go back to work consider this: export PATH=/home/yourusername/local/bin:$PATH has evaporated. It's not permanent; goes away when the shell is closed. To make it permanent you have to add that statement to .bash_profile. Here's mine:
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
PATH=$PATH:$HOME/bin
export PATH
export PATH=$HOME/local/bin:$PATH
export LD_LIBRARY_PATH=/home/myusername/local/lib
unset USERNAME
I found it necessary to reassert the LD_LIBRARY_PATH in order to make sqlite3 function, even though I had compiled sqlite3 and done that export prior to building Python.
Note that this .bash_profile invokes .bashrc. Depending on how Dreamhost has arranged things, you may have to put these exports in .bashrc.
Likewise, when you return to the shell myvirtenv will not be found to still be activated even if you never typed-in "deactivate". You only activate it temporarily in the shell to install stuff inside it and to start your server or run some other program that you've installed. Thereafter, the installed stuff knows to use the Python interpreter that has been copied to myvirtenv. To make that not happen, to make the stuff run off of the system Python interpreter you have to do what the aforementioned official virtualenv docs on mod_python, mod_wsgi say.
It looks as though this may be necessary even if you have not built your own Python, because otherwise you would have two Python interpreters running in the same server process. I am however sketchy on this. Flask is, like Django, a Python framework. An A2 Hosting tutorial--- they use Phusion Passerger too--- may be of interest. On their site search for "Django shared" and the tutorial will come up on top. Note that Chris C.'s instructions there tell you to use the --python=/path/to/python switch. In your case that could be /home/myusername/local/bin/python if you have locally installed Python, but in their case it's /usr/bin/python2.6. I think that their point is they don't want to get tech-support tickets from customers on problems caused by upgrades to their system python2.6 that could break your site. So that --python switch (-p directory is the short form; --python=directory is the long form) is to freeze the Python that your app will be using, to avoid such problems. It does so by copying all of the Python into your virtual environment, not just the interpreter.
I don't understand how they are avoiding the problem of mod_wsgi and the customer's apps using two different interpreters, but maybe that's what Phusion Passenger helps out with.