I have a virtualenv created for Python 2.5 and want to "upgrade" it to Python 2.6.
Here is how it was originally set up:
virtualenv --no-site-packages -p python2.5 myenv
I now run virtualenv in the same directory to upgrade:
virtualenv --no-site-packages -p python2.6 myenv
...
Not overwriting existing python script myenv/bin/python (you must use myenv/bin/python2.6)
...
Overwriting myenv/bin/activate with new content
The default python is still 2.5, even though I can also specify 2.6. Is there any way to remove 2.5 entirely and have 'bin/python' point to 2.6 instead?
You can use the Python 2.6 virtualenv to "revirtual" the existing directory. You will have to reinstall all the modules you installed though. I often have a virtual directory for developing a module, and virtualenv the same directory with many versions of Python, and it works just fine. :)
In Python 3.3+ venv supports --upgrade flag
--upgrade Upgrade the environment directory to use this version
of Python, assuming Python has been upgraded in-place.
Usage:
python -m venv --upgrade YOUR_VENV_DIRECTORY
I just upgraded my venv from Python 3.7.x to 3.8 on several projects without any issue.
You should create a new virtualenv using python2.6 and then, after activating the new env, use its python2.6 and its easy_install to install new versions of any site packages you need. Beware that the path name to the virtualenv is hardwired into various files within the environment, so, when you are ready to switch over to it, either change your startup scripts et al to refer to the new virualenv path or be very careful about copying it over to the old directory and modifying the path names inside it.
Install a second Python on CentOS
download python
install to diff local
configure --prefix=/opt/virtualenv/python
make && make install
create virtual env using new python
virtualenv /opt/virtualenv --python=/opt/python276/bin/python
note: if needed it can be done with a different user
chown pyuser -R /opt/virtualenv
su - pyuser
source /opt/virtualenv/bin/activate
python -v
Create virtual env:
virtualenv /opt/virtualenv
su - infograficos
source bin/activate
Install pip with python 2.7 (inside virtualenv)
easy_install pip
If you're using OS X, try this if you want to upgrade Python to a minor-increased version (e.g. 2.7.6 to 2.7.8) while keeping third-party libraries work.
It work for me on 5 different virtual environments with Django installed.
You can simply do this by go to your venv file and change the python path and it's version from pyvenv.cfg like this:enter image description here
Related
I use Python and pip trhough the asdf version manager, and in my older PC, when I create a new venv it already came with some default packages. I'm now using a newer verison of python (3.9.12) and pip (22.0.4), and it does not come with basic and essential things, such as the gnureadline, to be able to see the commands history in the python's shell. It's really annoying having to install it again in all new venvs and I'm trying to avoid an alias to create a venv and install what I want inside it. There is a way to set some default packages to all venvs?
There is an option:
--system-site-packages
Give the virtual environment access to the system
site-packages dir.
So if you use python3 -m venv --system-site-packages .venv then you may install the packages you want available to all envs at the system level. You'll have to be hygienic about the packages installed at the system level.
If the system python on your distribution is a hot mess, and you can't remove things you don't want visible in venvs from it, then you'll want to look for another option.
One possibility is just to install common packages to some target directory:
python3 -m pip install dep1 dep2 --target=/path/to/common
And then make this directory of packages always visible:
export PYTHONPATH=/path/to/common
After moving over to Fedora (from Windows), I realized that it came with both installations of Python 2.7.5 and Python 3.6.6.
As I familiarized myself with using Python, I learned of the great utilities of virtual environments and how organized they keep everything.
However, my current dilemma is for which Python version should I do pip(2 or 3) install virtualenv virtualenvwrapper.
From my research, I understand that the virtualenvwrapper provides the ability to create a virtual environment using a specified version of Python: mkvirtualenv -p /usr/bin/python(2 or 3) {name}.
Therefore, should I only install virtualenv and virtualenvwrapper on one of the Python versions and use the aforementioned feature? Or should I install virtualenv and virtualenvwrapper on both versions of Python.
Would there be any conflicts?
Edit
More importantly, assuming that I have virtualenv and virtualenvwrapper installed for both Python 2.7.5 and Python 3.6.6, which version's command is called when I run any of the following: workon, mkvirtualenv, rmvirtualenv, etc.?
Would there be any conflicts?
Not until you mistakenly run the default system python command with a script that's using the opposite version as compared to the more specific python2 or python3 commands.
The virtualenvs do not conflict, and must be activated to be used. You can also of course have as many virtualenv's as you wish.
To avoid any problems setting up an environment, its suggested to run python2 -m virtualenv for example, rather than simply virtualenv command itself
For the commands listed at the bottom of the question, it depends on how your PATH is configured. Personally, I use pyenv rather than virtualenv directly, which injects itself into the OS PATH variable
How can I install pygame on both python 2 and 3 on the same computer?
Its working with python 2 but i cant install it on python 3.
Use virtualenv. It will allow each project to have its own version of python and keeps all its python packages stored next to the project, rather than globally on the system.
cd into your project directory
Install a version of python 2 on your system
$ virtualenv p2env --python=2.7
Install a version of python 3 on your system
$ virtualenv p3env --python=3.5
You can how "activate" either of those environments.
$ ./p2env/bin/activate
You'll see your command prompt gets prefixed with the name of the environment. You're now running under that version of python. Additionally, any packages you pip install will be installed locally for that specific environment.
To deactivate the environment type the following.
$ deactivate
You should notice the environment name is removed from the command prompt. You're now able to switch to a new environment if you wish.
Make sure you add the environment directories virtualenv created to your .gitignore file.
/p2env
/p3env
Of course you can. Most linux distributions do so:
~$ python
python python2 python2.7 python3 python3.4 python3.4m python3m
~$ python
Debian symlinks python to python2.7 so you need to run python3 explicitly. On all other systems you can also have multiple versions in parallel in the same fashion.
Also there is a tool virtualenv which might help you in creating and manageing completely isolated python environments. (https://virtualenv.pypa.io/en/stable/)
I am trying to start a Python 3.6 project by creating a virtualenv to keep the dependencies. I currently have both Python 2.7 and 3.6 installed on my machine, as I have been coding in 2.7 up until now and I wish to try out 3.6. I am running into a problem with the different versions of Python not detecting modules I am installing inside the virtualenv.
For example, I create a virtualenv with the command: virtualenv venv
I then activate the virtualenv and install Django with the command: pip install django
My problems arise when I activate either Python 2.7 or 3.6 with the commands
py -2 or py -3, neither of the interactive shells detect Django as being installed.
Django is only detected when I run the python command, which defaults to 2.7 when I want to use 3.6. Does anyone know a possible fix for this so I can get my virtualenv working correctly? Thanks! If it matters at all I am on a machine running Windows 7.
Create virtual environment based on python3.6
virtualenv -p python3.6 env36
Activate it:
source env36/bin/activate
Then the venv36 has been activated, venv36's pip is available now , you can install Django as usual, and the package would be stored under env36/lib/python3.6/site-packages:
pip install django
You have to select the interpreter when you create the virtualenv.
virtualenv --python=PYTHON36_EXE my_venv
Substitute the path to your Python 3.6 installation in place of PYTHON36_EXE. Then after you've activated, python executable will be bound to 3.6 and you can just pip install Django as usual.
The key is that pip installs things for a specific version of Python, and to a very specific location. Basically, the pip command in your virtual environment is set up specifically for the interpreter that your virtual environment is using. So even if you explicitly call another interpreter with that environment activated, it will not pick up the packages pip installed for the default interpreter.
I have a system with CentOS installed. It currently runs python2.6, but python2.7 is also installed.
I want to run django 1.7, which is also currently installed. If I run django outside of a virtualenv, it is using python2.6 by default. I didn't install it myself.
What I assume is a way to get around this is to create a virtualenv. Which I've done, and used --python=python2.7. But when I create the virtualenv, and install a new django 1.7 in it (with pip), it still uses python2.6 instead of 2.7.
Since I'm doing this all through ssh, I'd like an easy way around it (rather than compiling from source, etc). Is there a way to specify that django uses python2.7 when I install it with pip in the virtualenv? Or what is the right way to correct this issue?
Here is what I have done:
ssh into account.
$ mkdir project; cd project
$ virtualenv env --python=python2.7
$ cd env
$ source bin/activate
$ sudo easy_install-2.7 pip
$ pip install django==1.7
Then I go into my python interpreter. The interpreter is running 2.7 and if I import django, it all works okay. But as soon as I run
django-admin.py startproject project_name
it is back to using 2.6.
Invoke django-admin.py like this python django-admin.py, in your activate virtualenv. Alternatively you can do /path/to/virtualenv/bin/python django-admin.py.
The best solution is probably adding a shebang to django-admin.py that looks like #!/usr/bin/env python which should use the python interpreter of your active virtualenv. See https://stackoverflow.com/a/2255961/639054
You could use pyenv, which will allow you to set your Python interpreter based on what directory you're in. I also use it with pyenv-virtualenv so that I get all the benefits of isolating my packages per application.
There's a bit of a learning curve, but it's worth it if you need to switch Python interpreters to match a production server for instance.