So, i have python 3.11 installed, i wanted to run a code with flask module, and it was running using original python, but not in vscode, so i followed a suggestion from stack exchange and used command python -m venv env.
This created a new folder called env, and after that i got a prompt that new virtual environment has been created, do you want to use it for the workspace folder, i said yes, and still nothing worked. And now even other modules are not being recognized either by vscode or the original python.exe.
I am a novice in programming and have no idea what to do, please help.
Thanks
Once a venv is created, you must activate it like so: C:\User\venv_folder\Scripts\ activate
If this doesn't work try using C:\User\venv_folder\Scripts\ activate.ps1 or activate.bat
You'll know if it works once you have the (venv_name) before your command line in the terminal
python -m venv env
According to the docs. Running this command creates the target directory (creating any parent directories that don’t exist already) and places a pyvenv.cfg file in it with a home key pointing to the Python installation from which the command was run (a common name for the target directory is .venv). It also creates a bin (or Scripts on Windows) subdirectory containing a copy/symlink of the Python binary/binaries (as appropriate for the platform or arguments used at environment creation time). It also creates an (initially empty) lib/pythonX.Y/site-packages subdirectory (on Windows, this is Lib\site-packages). If an existing directory is specified, it will be re-used.
I think what you need more is to create a conda environment. Use the following command to create it (take python 3.10.4 as an example), and then you can manually select it in python interpreter.
conda create -n env-01 python=3.10.4
You can also read vscode docs for more details.
Related
i try to install curses module on windows and it ends with this error
picture:https://i.stack.imgur.com/fbKCJ.png
You can't install windows curses with 3.10 yet. It is supported on 3.9. I don't know when it will be supported for 3.10, so your best option for now is just to install 3.9.
You can make a virtual environment with python 3.9 for any projects that need to use curses. A virtual environment makes a copy of your python interpreter and installs it into a directory of your choice. You use this by "activating" the virtual environment, and as long as you're inside that environment, anything you install will be contained by this copied installation.
This allows you to run different versions of python, and it also allows you to install packages that you don't want cluttering up your main installation. It's a good idea to use this for all projects that are going to need packages outside of the standard library (anything that you pip install).
To make a virtual environment with your default interpreter, type:
python -m venv <envname> where <envname> is whatever you want the environments directory to be called. This is usually env.
So python -m venv env would install a fresh copy of your python 3.10 to a folder called env inside your current directory.
You activate this by typing .\<envname>\scripts\activate
You'll then get a prompt that has (<envname>) in front of it, which will let you know you're in that environment.
You can leave that environment by typing deactivate.
In order to use a different version, you have to run venv with the interpreter you want to use on the project. So if you wanted to use python 3.9, it would be something like
"C:\Program Files\Python39\python.exe" -m venv env depending on where you installed python 3.9. The directory I used is usually the default directory when installing for all users.
To more easily work with other versions on windows, I make batch files for each one and put them in a utils folder that's on my system path. (I'll explain how to add a folder to the system path at the bottom if you don't know.)
So make a file called python39.bat, and into that, put "C:\Program Files\Python39\python.exe" %*. (Or wherever the installation is. %* just expands other arguments so you can use it exactly like you would the other executable.
That way you can create a new python 3.9 virtual environment with python39 -m venv env (along with any other arguments you want) instead of typing out the full path.
You can also use --prompt to change the name displayed by your virtual environment instead of changing the name of the folder. This is useful for making it shorter or just keeping things straight when you're using a bunch of environments for different projects. (Using the same folder name allows you have something that doesn't change into your standard ignore files.)
So anyway, here's an example of the full process after you install python 3.9.
Go to your project directory or wherever you'd like to install the environment.
type "C:\Program Files\Python39\python.exe" -m venv env (optional) --prompt somealternatenametodisplay (or python39 -m venv env if you made a .bat file).
type .\env\scripts\activate
You should now have (env) or the alternate name at the beginning of your prompt
type pip install windows-curses
And everything should work now. Just remember to activate your environment whenever you want to use this.
(To put a folder on the path)
Let's make a new folder called myutils as an example at C:\myutils
and put python39.bat in that folder.
Right click My Computer
Select properties
On the right side under Related settings click on Advanced system settings.
At the bottom of the Advanced tab, click on Environment Variables
(You can also get to Environment Variables much faster by opening the start menu and starting to type environment, which should give you Edit the system environment variables).
Under System variables, select Path, and then click Edit...
Type C:\myutils, hit Enter, and press OK.
Now, open a new terminal, and you'll be able to access any programs you put in that folder.
In your path variable in Environment Variables, you can also change the default python interpreter. The default will be whichever one is at the top (which will probably be 3.9 now that you've just installed it).
To change it back to 3.10, select C:\Program Files\Python310\Scripts\ and click Move Up until it's above the Python39 entries, then do the same with C:\Program Files\Python310\.
GO to this URL and find your python version and download wheel file from it
As from my image it is python 3.7 with 64 bit so i will download this file
windows_curses-2.2.0-cp37-cp37m-win_amd64.whl and give whole path where it is downloaded
and give full path for installation like
pip install filepath\windows_curses-2.2.0-cp37-cp37m-win_amd64.whl in cmd or powershell
Why does python -m venv py38 use the system python still??
This just burned my pretty severely, I had a very customized python 3.8 environment that I thought was isolated from the system as advertised by venv, my system python just upgraded to 3.9 and now I have to re-build everything.
Any suggestions on a way to create actually isolated python environments would be appreciated.
https://docs.python.org/3/library/venv.html
Running this command creates the target directory (creating any parent directories that don’t exist already) and places a pyvenv.cfg file in it with a home key pointing to the Python installation from which the command was run (a common name for the target directory is .venv). It also creates a bin (or Scripts on Windows) subdirectory containing a copy/symlink of the Python binary/binaries (as appropriate for the platform or arguments used at environment creation time).
This makes me think that it's possible to have not a copy of the python installation but a link to it.
Anyway pyenv.cfg should have the path of your python, I suggest to change it.
I have two questions about Python as it relates to PATH. First, I wanted to show you how my computer is set up. Right now I have python stored directly on my C drive like so:
The folder "Python" is Python 3.8.3. Now, here are the folders in my PATH environment variable:
My first question is why is that when I type "python" on my terminal (at any path), it launches the python.exe? As of right now, pip install commands and the python command works no matter what path I navigate. I thought that in order for this to happen, you would have to add the folder to where the python.exe was stored to your PATH variable (and the same goes for pip script). To my understanding, python is no where to be found in my environment variable set-up.
My second question is how would I make it to where Python 3.9.1 launches when I type "python" in the command prompt instead of the older version? Likewise, I would like to be able to use this newer version of pip when I type "pip install blabla."
My first question is why is that when I type "python" on my terminal (at any path), it launches the python.exe? As of right now, pip install commands and the python command works no matter what path I navigate. I thought that in order for this to happen, you would have to add the folder to where the python.exe was stored to your PATH variable (and the same goes for pip script). To my understanding, python is no where to be found in my environment variable set-up.
To answer why it works currently, it appears your screenshot is showing your system variables, but it is possible that your Path set in your user variables on your system point to your C:\Python directory. Check your User variables to make sure it isn't set there.
My second question is how would I make it to where Python 3.9.1 launches when I type "python" in the command prompt instead of the older version? Likewise, I would like to be able to use this newer version of pip when I type "pip install blabla."
I would direct you to the python configuration docs. It talks about how to setup your environment to point to the new installation of python. In short, you'd modify your path variable to point to the directory where the new version of python.exe is saved. You also want to add the \Scripts directory that can be found in that directory to your path. That will allow you to use the expected version of pip from the command prompt.
I want VS Code to turn venv on run, but I can't find how to do that.
I already tried to add to settings.json this line:
"terminal.integrated.shellArgs.windows": ["source${workspaceFolder}\env\Scripts\activate"]
But, it throws me an 127 error code. I found what 127 code means. It means, Not found. But how it can be not found, if I see my venv folder in my eyes right now?
I think it's terminal fault. I'm using Win 10 with Git Bash terminal, that comes when you install Git to your machine.
This is how I did it in 2021:
Enter Ctrl+Shift+P in your vs code.
Locate your Virtual Environment:
Python: select interpreter > Enter interpreter path > Find
Once you locate your virtual env select your python version:
your-virtual-env > bin > python3.
Now in your project you will see .vscode directory created open settings.json inside of it and add:
"python.terminal.activateEnvironment": true
don't forget to add comma before to separate it with already present key value pair.
Now restart the terminal.
You should see your virtual environment activated automatically.
Actually the earlier suggested solutions didn't work for me, instead I added the following in my settings:
"settings": {
"python.terminal.activateEnvInCurrentTerminal": true,
"python.defaultInterpreterPath": "~/venv/bin/python"
}
Of course replace the defaultInterpreterPath (used to be pythonPath) setting with your own path (so don't copy/paste the second line).
You don't need this line at all. Just remove it and switch your Python interpreter to point to the one within your venv. Here's a relevant documentation (italicized emphasis mine):
To select a specific environment, use the Python: Select Interpreter
command from the Command Palette (Ctrl+Shift+P).
... and
opening a terminal with the Terminal: Create New Integrated Terminal
command. In the latter case, VS Code automatically activated the
selected environment.
Once you switch the interpreter VS code should create a .vscode folder within your workspace with a settings.json indicating the python interpreter. This will give VS code the direction of where to locate the venv.
There is a new flag that one can use: "python.terminal.activateEnvironment": true
my scenario was pretty much the same. I am running VSCode on Windows, wanting to used git bash as my default Terminal but after the venv got created, it was doing some weird stuff when a Terminal would open where it couldn't find the correct python interpeter in the venv/Scripts folder even though I did ctrl-shift-p a bunch of times to reset it to the python.exe there. I also wanted to make sure the activate script was run on Terminal open. I just couldn't get the debugger to work right and it kept complaining that it could not find the python interpreter, so I basically couldn't debug at all.
So for anyone who is having weird stuff happen trying to use a Git Bash Terminal in VSCode in Windows related to a python project using a virtual env, here is what I found out;
I noticed that when I opened a new Git Bash Terminal, and looked at the $PATH variable to make sure it could find the interpreter in the venv, the path to the venv/Scripts folder would be prepended to the $PATH, but not with linux path separators like everything else in $PATH but with a Windows style path;
echo $PATH
C:\Users\blah\Documents\blah\Stock-down\Dev\this_api\venv/Scripts:/c/Users/blah/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mingw64/bin:/usr/bin:/c/Users/blah/bin:/c/Program Files/Go/bin:/c/Python39/Scripts:
So whenever I would try to debug, or just even run which python, It would get confused and thought the interpreter was in here;
which python
C:\Users\blah\Documents\blah\Stock-down\Dev\this_api\venv/Scripts/C/Users/blah/Documents/blah/Stock-down/Dev/this_api/venv/Scripts/python.exe
I ran the "printenv" command in the Terminal to see what env vars were getting set and why the venv interpreter path was getting messed up. And I found a env var I didn't know existed - VIRTUAL_ENV. But I didn't know how it was getting set or where it came from. After some pain, and hunting around I found it - when you run "python -m venv venvname" to create the virtual env in the project folder, as you know, it creates the activate (and activate.bat for windows) scripts in the ./venv/Scripts folder. Inside these files this VIRTUAL_ENV variable is not only exported, but but prepended to the $PATH variable on Terminal open with the "/Scripts" folder name added in linux path style. The problem with is that it sets the VIRTUAL_ENV value with windows type path - I know its painful and wrong to do this, but I just changed it to what Git Bash is expecting, see below;
#unset irrelevant variables
deactivate nondestructive
#VIRTUAL_ENV="C:\Users\blah\Documents\blah\Stock-down\Dev\this_api\venv"
VIRTUAL_ENV="/c/Users/blah/Documents/blah/Stock-down/Dev/st_api/venv"
export VIRTUAL_ENV
_OLD_VIRTUAL_PATH="$PATH"
PATH="$VIRTUAL_ENV/Scripts:$PATH"
export PATH
Now when a new Git Bash Terminal is opened it prepends the venv/Scripts path correctly to $PATH;
echo $PATH
/c/Users/blah/Documents/blah/Stock-down/Dev/st_api/venv/Scripts:/c/Users/blah/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mingw64/bin:/usr/bin:/c/Users/blah/bin:/c/Program Files/Go/bin:/c/Python39/Scripts:
I also made a copy of the executable python.exe in the ./venv/Scripts dir and just called it "python" and now the command "which python" works and I can debug fine. I still set ctrl-shift-P when I choose the interpreter in VSCODE to "python.exe" when I just use "find" during the selection.
For more information on VIRTUAL_ENV var, see this doc -- python venv docs
It feels like jumping through a bunch of hoops I know, but this way I can open a new Git Bash Terminal, have the activate script run correctly on Terminal Open, debug, and operate normally without having to float between Git Bash AND WSL Ubuntu AND Powershell, etc.
My environment started to activate automatically after the advice from this article
When you create a new virtual environment, a prompt will be displayed
to allow you to select it for the workspace. This will add the path to
the Python interpreter from the new virtual environment to your
workspace settings. That environment will then be used when installing
packages and running code through the Python extension. For examples
of using virtual environment in projects, see the Python, Django, and
Flash tutorials.
My solution was to create /.vscode/settings.json manually
Here is the tree;
├───django
│ ├───.vscode
│ │ ├───settings.json
I created /.vscode/settings.json then added this code in settings.json (I am using windows so I used double backslash for path location otherwise it gives unicode error, and don't copy paste this, find your own .virtualenvs)
{
"python.defaultInterpreterPath": "C:\\Users\\Talha\\.virtualenvs\\django-okd21pq9\\Scripts\\python.exe"
}
I am trying to get a django project up and running, and I have django running, but I am having trouble with python's virtualenv.
here is my error (on terminal open this shows up)
/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: No module named virtualenvwrapper
virtualenvwrapper.sh: There was a problem running the initialization hooks.
If Python could not import the module virtualenvwrapper.hook_loader,
check that virtualenvwrapper has been installed for
VIRTUALENVWRAPPER_PYTHON=/Library/Frameworks/Python.framework/Versions/2.7/bin/python and that PATH is
set properly.
Here is what My .bash profile looks like:
# Setting PATH for Python 3.4
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.4/bin:${PATH}"
export PATH
# Setting PATH for Python 2.7
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}"
export PATH
export WORKON_HOME=$HOME/.virtualenvs
source /Library/Frameworks/Python.framework/Versions/3.4/bin/virtualenvwrapper.sh
export PIP_VIRTUALENV_BASE=$WORKON_HOME
if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi
I am pretty new to command line stuff and virtual environments, so I might not know some "obvious" things I am doing wrong. Thanks.
First some basics of the command-line shell:
PATH is an environment variable that contains a list of filesystem directories. When you type a command such as ls, python or virtualenvwrapper.sh your shell will search each directory starting from the first one listed. To see your current PATH type:
$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
To see what a given command is going to resolve to the location of the program that is going to be run, use the which command:
$ which ls
/bin/ls
Now in your example you are first adding a Python 3.4 location to your PATH and then a Python 2.7 location. The latter location is going to be first on your PATH. So all your Python related commands are first going to try and run Python 2.7, if a command isn't found there, it next searches in your Python 3.4 installation.
You appear to have installed virtualenvwrapper for Python 3.4, but when you run virtualenvwrapper.sh from the line:
source /Library/Frameworks/Python.framework/Versions/3.4/bin/virtualenvwrapper.sh
You are explicitly running the virtualenvwrapper.sh installed for Python 3.4. This runs a python command where your Python 2.7 is run, which does not appear to have virtualenvwrapper installed, as shown by this error message:
/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: No module named virtualenvwrapper
If you tried removing the Python 2.7 location addition to your PATH and it didn't work, you have to remember that changes to your .bash_profile are not automatically reflected in your terminal. You have to create a new terminal session and that new session will read your new .bash_profile.
If you are trying to get the command virtualenv to resolve to two different Pythons, it's simply not possible. It will always resolve to one specific Python based on the ordering of the locations on your PATH. VirtualEnv does install alternate versions of the command with the version of the Python built into the name. Use the commands virtualenv-3.4 and virtualenv-2.7 to create virtual environments for each different Python.
The key to all of this is remembering that PATH is used to resolve to an absolute path location of a program this is run. Use the echo $PATH and which commands to help you understand how that final path is being resolved.
It may seem tedious, but typing out the full absolute path is always going to side-step the magic of PATH resolution:
$ /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv
Try using smaller steps on your way to manipulating the path. Use just virutalenv-3.4 to make a Python 3.4 virtual environment and only bring in virtualenvwrapper as you need it and after your understanding of shell environments is more solid.
Finally, even pro's can get tripped up by playing games manipulating the path. You are ultimately trying to take a bunch of different application locations and flatten them all into one namespace. At some point conflicts can become unresolveable. A Python installation tool such as Buildout has it's own learning curve, but it hard-codes the absolute path to the python of each python script that it installs. Hard-coding absolute paths is the only way to deal with extreme corner cases such as having two builds of Python 3.4 side-by-side where you have two scripts which each need to run on two different builds of the same Python. Hard-coding absolute locations is also desirable in production environments, because then your application is immune to any changes to the bash shell. If you forget about a required ordering of your PATH, or another sysadmin tinkers with the PATH, you won't find your application breaking unexpectedly.