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
Related
I know it possible to have two installs of Python of different versions on a Windows system. But I cannot manage to have two installs of the same revision (in my case 3.8.10) to coexist.
I'm designing an application that creates a Python process. That process needs to run from a specific version of Python with packages of specific versions installed on it. In order to fully control the Python install, decision was made to install it inside the application distribution directory, segregating it from any other Python installed on the system. No environment variable refers to it.
As part of the the deployment/install process for the application, a PowerShell script downloads the Python installer and installs Python and the necessary packages into the application distribution directory. The Python installer is invoked as follows:
.\\python-3.8.10-amd64.exe /quiet InstallAllUsers=1 PrependPath=1 Include_test=0 TargetDir="$curDir\\Python" Include_exe=1 Include_lib=1 Include_pip=1 Include_tcltk=1 | Out-Null
It works well unless the system has already a Python install of the same version installed on it. In that case, running the installer will break the existing install, and not fully install the new one.
I tried to run the installer manually and I noticed that it is able, somehow, to detect that an install of the same revision exist on the system. In that case, it does not allow an new install. To do so, I would have to uninstall Python at its current location to be able to install it somewhere else.
Is there a way to have two distinct installs of Python 3 of the same revision on a Windows system? And if yes, how can it be done?
A better aproach instead of installing python again would be using virtual environments.
To create a new python env. Open the command line (Powershell) on Windows and navigate to the directory you want your python env to be.
Type python3 -m venv tutorial-env. This will create a new python virtual env named tutorial-env
To activate that env on Windows powershell type: tutorial-env\Scripts\activate.bat
To deactivate the env type deactivate
If you are wondering what python virtual environments do. They basically do what you are trying to do but without installing python globally again. When you create a new python env, a new python3 is placed in your env directory, in this case in the tutorial-env directory, and when you activate the environment, it replaces the python global path to the path in your env (in this case in tutorial-env). Now when you are on this virtual env and install new python packages, they will only be available when you activate that env.
For more information about virtual environments please refer to Python official docs.
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.
I need to create new virtual environment in PyCharm. There are already some files in the folder.
This is how my project looks like:
I want to create venv in heureka-negativni-reviews
I try: File -> New project.
I switch this settings:
to have Python 3.10 as an interpreter and to create venv in heureka-negativni-reviews
But when I click on create, I got:
EDIT:
I found that I am not able to select Python 3.10 as an interpreter:
But I cannot click OK when I select Python 3.10:
What is the problem, please?
Now we see the reason, why your IDE is not able to create your venv, since the command line isn't either, which is the set of commands your IDE typically uses.
The pip and pip3 belongs to python3.8 and that is another problem, if you want to install python packages for python 3.10, which isn't possible this time without system invention.
Also your python setup seems to be messed.
/home/vojta/Desktop/INTERNET_HANDEL/HEUREKA/heureka-negativni-reviews/venv/bin/python
seems not to be a general system path. It looks that you built your own version of python and installed it by a specific prefix. Installing python correctly is off the topic here.
There are different installers for different platforms which provide install instruction inside their archives.
Before doing this, it's recommended to clean up your messed installation first.
You may find information here and there.
It could also be, that you are trying to create another venv from within an already sourced venv. Such kind of composed venvs can lead to confusion and that would explain your path above a bit more, which contains /venv/.
Also manually remove all your custom python versions from your /home/vojta/ directory, like $ rm -r /home/vojta/Desktop/INTERNET_HANDEL
First ensure that the Python interpreter is added to the list available (by adding as an 'Existing environment').
Then add a venv via link
Then drag and drop your existing files to the venv directory.
before with venv after drag and drop
I wanted to replace Python 3.8 32-bit with the 64-bit version to install the face_recognition module, so I deleted the previous version and tried to re-route the project to the new Python version by going to File > Settings > Project Interpreter > Show all > Show Paths for Selected Interpreter, and adding all the Python files from the new folder and getting rid of the old ones.
However, it's still showing me this error when I try to install the module:
(Will2.0) C:\Users\solei\PycharmProjects\Will>pip install face_recognition
No Python at 'C:\Users\solei\AppData\Local\Programs\Python\Python38-32\python.exe'
I've also tried going to the Windows System Properties and changing everything that says "Python38-32" there, but it's still not working. It does work when I make a new environment, though, so at least I know that Python installed properly. It's just this one environment that is tripping me up (I'd prefer not to make a new project for this, btw. I've already installed a lot of modules in it.).
Your selected interpreter is not the system interpreter you've replaced with the 64-bit version, but your project's virtual environment interpreter. The virtual environment's files weren't changed in that process and need to be updated before you can use that environment again.
The system interpreter is your Python interpreter installed using the installation executable. In your case it is located in C:\Users\solei\AppData\Local\Programs\Python\Python38\. You can have multiple system interpreters installed, such as having Python 2.7, Python 3.7 and Python 3.8 side-by-side.
The virtual environment interpreter is a copy of another interpreter created using the venv package from the Python standard library. You can have many virtual environments interpreters in the system (one or more for every project, for example)
The base interpreter is the interpreter that was used as a template for the venv package. Every virtual environment interpreter has its base interpreter (usually a system interpreter) that it requires to run. Changing or upgrading the base interpreter requires updating the virtual environment.
If we take a quick look at the documentation, a virtual environment is described as
a self-contained directory tree that contains a Python installation for a particular version of Python, plus a number of additional packages.
That means you can setup an individual environment for every project, which will contain its own packages. The environment is a very efficient way of managing project packages, that's why PyCharm suggests a creation of such environment over the system interpreter by default. In short, it allows you to have two different versions of the same package used by two different projects, without the packages conflicting with each other.
This also explains why your virtual environment files weren't affected by your upgrade.
Now, I am unfortunately no Python expert. I had to spend some time examining how Python handles virtual environments on Windows and Ubuntu. It seems the environment always requires the base system interpreter present in the system. If you remove or change the location of the base interpreter, the environment will fail to function.
As I mentioned before editing this answer, you can in theory simply edit the pyenv.cfg file located in the root folder of the virtual environment. In practice, that will only work in simple cases and it is not the intended way of updating virtual environments.
You need to upgrade your virtual environment's files to work with your new system interpreter. That can mean the 64-bit version over the 32-bit version, or even a newer version of Python - such us upgrading from 3.7 to 3.8.
Close PyCharm
Check if the system interpreter you want to upgrade to is on the system Path
You can quickly check by running
python -c "import platform; print(platform.architecture())"
For you, the output should look like this
('64bit', 'WindowsPE')
If your output is different, you'll need to prefix the absolute path to the Python executable in step 4).
Navigate to the virtual environment's directory
The directory you're looking for contains the Include, Lib and Scripts directories and the pyenv.cfg file. From your screenshots, it seems this directory is your project's root directory, so in your case:
cd C:\Users\solei\PycharmProjects\Will2.0\
Upgrade the virtual environment
python -m venv --upgrade .
... or if Python is not on your path
C:\Users\solei\AppData\Local\Programs\Python\Python38\python.exe -m venv --upgrade .
The . in the commands refers to the current directory.
Open PyCharm and verify your environment is working correctly
... or simply try to run pip directly from the command line. Note you need to first activate the virtual environment by running the Scripts\activate.bat batch file.
If the above-mentioned method doesn't work, you might have to create a new virtual environment. You can create one easily without making a new PyCharm project. See this PyCharm documentation for reference. However, you'll still need to redownload all the required packages again.
For the simplicity, I recommend creating the new virtual environment in a .venv folder located in the project's root.
Disclaimer
I tested only the Python's behavior alone on a fresh Windows installation inside the Windows Sandbox. I was able to install the 32-bit Python, create a virtual environment, replace Python with the 64-bit version and upgrade the virtual environment to have it launch correctly again.
Using Python 3.7.0 on Mac. Trying to use venv module that was added post python 3.4.
I setup my virtual env using python3 venv -m path/to/my/dir - my question is do I need to activate this virtual env to use?
The documentation seem to imply I don't need to?
You don’t specifically need to activate an environment; activation just prepends the virtual environment’s binary directory to your path, so that “python” invokes the virtual environment’s Python interpreter and you can run installed scripts without having to use their full path. However, all scripts installed in a virtual environment should be runnable without activating it, and run with the virtual environment’s Python automatically.
If I don't have to activate, what is the benefit of prepending venv to binary directory? Wouldn't this have to happen regardless for a venv to work?
Activating the virtualenv gives you convenience. It is never required.
Even for scripts that are configured to run with #!/usr/bin/env python, (which looks up the python executable on your path), you could manually update the PATH environment variable:
$ PATH="/path/to/venv/bin" some_script
Activating makes the PATH update stick until you deactivate again, and that can be convenient.
For example, I regularly have several virtualenvs in use at any one time. Some of them are there only to install some command-line tools I have symlinked into my ~/bin/ directory, another is home to a Jupyter notebook, and 2 more are used to quickly verify code snippets in different Python versions with access to 3rd-party libraries. I don't activate any of those.
When you don’t activate a virtualenv, all that happens is that your terminal PATH variable is not updated to put the bin directory of the virtualenv first, so when you enter python or pip or other script without any path into the terminal, the shell will find a different Python binary to run. You can always use any of the commands in the virtualenv bin/ directory by giving the full path to that command.