Installing Multiple Versions of a Package with Pip

Installing multiple versions of a package with pip

pip won't help you with this.

You can tell it to install a specific version, but it will override the other one. On the other hand, using two virtualenvs will let you install both versions on the same machine, but not use them at the same time.

You best bet is to install both version manually, by putting them in your Python path with a different name.

But if your two libs expect them to have the same name (and they should), you will have to modify them so they pick up the version they need with some import alias such as:

import dependencyname_version as dependencyname

There is currently no clean way to do this. The best you can hope is for this hack to work.

I'd rather ditch one of the two libs and replace it with an equivalent, or patch it to accept the new version of the dependency and give the patch back to the community.

Dealing with multiple Python versions and PIP?

The current recommendation is to use python -m pip, where python is the version of Python you would like to use. This is the recommendation because it works across all versions of Python, and in all forms of virtualenv. For example:

# The system default python:
$ python -m pip install fish

# A virtualenv's python:
$ .env/bin/python -m pip install fish

# A specific version of python:
$ python-3.6 -m pip install fish

Previous answer, left for posterity:

Since version 0.8, Pip supports pip-{version}. You can use it the same as easy_install-{version}:

$ pip-2.5 install myfoopackage
$ pip-2.6 install otherpackage
$ pip-2.7 install mybarpackage

EDIT: pip changed its schema to use pipVERSION instead of pip-VERSION in version 1.5. You should use the following if you have pip >= 1.5:

$ pip2.6 install otherpackage
$ pip2.7 install mybarpackage

Check https://github.com/pypa/pip/pull/1053 for more details

References:

https://github.com/pypa/pip/issues/200
~~http://www.pip-installer.org/docs/pip/en/0.8.3/news.html#id4~~

https://pip.pypa.io/en/stable/news/#v0-8 or

https://web.archive.org/web/20140310013920/http://www.pip-installer.org:80/docs/pip/en/0.8.3/news.html#id4

How to install multiple python packages at once using pip

For installing multiple packages on the command line, just pass them as a space-delimited list, e.g.:

pip install wsgiref boto

For installing from a text file, then, from pip install --help:

-r FILENAME, --requirement=FILENAME
Install all the packages listed in the given requirements file. This option can be used multiple times.

Take a look at the pip documentation regarding requirements files for their general layout and syntax - note that you can generate one based on current environment / site-packages with pip freeze if you want a quick example - e.g. (based on having installed wsgiref and boto in a clean virtualenv):

$ pip freeze
boto==2.3.0
wsgiref==0.1.2

Installing specific package version with pip

TL;DR:

Update as of 2022-12-28:

pip install --force-reinstall -v

For example: pip install --force-reinstall -v "MySQL_python==1.2.2"

What these options mean:

--force-reinstall is an option to reinstall all packages even if they are already up-to-date.
-v is for verbose. You can combine for even more verbosity (i.e. -vv) up to 3 times (e.g. --force-reinstall -vvv).

Thanks to @Peter for highlighting this (and it seems that the context of the question has broadened given the time when the question was first asked!), the documentation for Python discusses a caveat with using -I, in that it can break your installation if it was installed with a different package manager or if if your package is/was a different version.

Original answer:

pip install -Iv (i.e. pip install -Iv MySQL_python==1.2.2)

What these options mean:

-I stands for --ignore-installed which will ignore the installed packages, overwriting them.
-v is for verbose. You can combine for even more verbosity (i.e. -vv) up to 3 times (e.g. -Ivvv).

For more information, see pip install --help

First, I see two issues with what you're trying to do. Since you already have an installed version, you should either uninstall the current existing driver or use pip install -I MySQL_python==1.2.2

However, you'll soon find out that this doesn't work. If you look at pip's installation log, or if you do a pip install -Iv MySQL_python==1.2.2 you'll find that the PyPI URL link does not work for MySQL_python v1.2.2. You can verify this here: http://pypi.python.org/pypi/MySQL-python/1.2.2

The download link 404s and the fallback URL links are re-directing infinitely due to sourceforge.net's recent upgrade and PyPI's stale URL.

So to properly install the driver, you can follow these steps:

pip uninstall MySQL_python
pip install -Iv http://sourceforge.net/projects/mysql-python/files/mysql-python/1.2.2/MySQL-python-1.2.2.tar.gz/download

How to install multiple versions of Python in Windows?

Your questions depend a bit on "all the other software". For example, as @leiyang indicated, the answer will be different if you use conda vs just pip on vanilla CPython (the standard Windows Python).

I'm also going to assume you're actually on Windows, because on Linux I would recommend looking at pyenv. There is a pyenv-win, which may be worth looking into, but I don't use it myself because it doesn't play as nice if you also want (mini)conda environments.

1. (a) How do I install multiple Python versions?

Simply download the various installers and install them in sensible locations. E.g. "C:\Program Files\Python39" for Python 3.9, or some other location where you're allowed to install software.

Don't have Python add itself to the PATH though, since that'll only find the last version to do so and can really confuse things.

Also, you probably want to use virtual environments consistently, as this ties a specific project very clearly to a specific Python version, avoiding future confusion or problems.

1. (b) "3.8.1, 3.8.2 till 3.8.13" which should I pick?

Always pick the latest 3.x.y, so if there's a 3.8.13 for Windows, but no 3.8.14, pick that. Check if the version is actually available for your operating system, sometimes there are later versions for one OS, but not for another.

The reason is that between a verion like 3.6 and 3.7, there may be major changes that change how Python works. Generally, there will be backwards compatibility, but some changes may break how some of your packages work. However, when going up a minor version, there won't be any such breaking changes, just fixes and additions that don't get in the way of what was already there. A change from 2.x to 3.x only happens if the language itself goes through a major change, and rarely happens (and perhaps never will again, depending on who you ask).

An exception to the "no minor version change problems" is of course if you run some script that very specifically relies on something that was broken in 3.8.6, but no fixed in 3.8.7+ (as an example). However, that's very bad coding, to rely on what's broken and not fixing it later, so only go along with that if you have no other recourse. Otherwise, just the latest minor version of any version you're after.

Also: make sure you pick the correct architecture. If there's no specific requirement, just pick 64-bit, but if your script needs to interact with other installed software at the binary level, it may require you to install 32-bit Python (and 32-bit packages as well). If you have no such requirement, 64-bit allows more memory access and has some other benefits on modern computers.

2. Why does Python have such heavy dependency on the exact versions of libraries and packages etc?

It's not just Python, this is true for many languages. It's just more visible to the end user for Python, because you run it as an interpreted language. It's only compiled at the very last moment, on the computer it's running on.

This has the advantage that the code can run on a variety of computers and operating systems, but the downside that you need the right environment where you're running it. For people who code in languages like C++, they have to deal with this problem when they're coding, but target a much smaller number of environments (although there's still runtimes to contend with, and DirectX versions, etc.). Other languages just roll everything up into the program that's being distributed, while a Python script by itself can be tiny. It's a design choice.

There are a lot of tools to help you automate the process though and well-written packages will make the process quite painless. If you feel Python is very shakey when it comes to this, that's probable to blame on the packages or scripts you're using, not really the language. The only fault of the language is that it makes it very easy for developers to make such a mess for you and make your life hard with getting specific requirements.

Look for alternatives, but if you can't avoid using a specific script or package, once you figure out how to install or use it, document it or better yet, automate it so you don't have to think about it again.

3. Do virtual environments copy all the files from the main Python installation to create a virtual environment and then install specific packages inside it? Isn't that a lot of wasted resources in duplication because almost all projects require there own virtual environment.

Not all of them, but quite a few of them. However, you still need the original installation to be present on the system. Also, you can't pick up a virtual environment and put it somewhere else, not even on the same PC without some careful changes (often better to just recreate it).

You're right that this is a bit wasteful - but this is a difficult choice.

Either Python would be even more complicated, having to manage many different version of packages in a single environment (Java developers will be able to tell you war stories about this, with their dependency management - or wax lyrically about it, once they get it themselves).

Or you get what we have: a bit wasteful, but in the end diskspace is a lot cheaper than your time. And unlike your time, diskspace is almost infinitely expandable.

You can share virtual environments between very similar projects though, but especially if you get your code from someone else, it's best to not have to worry and just give up a few dozen MB for the project. On the upside: you can just delete a virtual environment directory and that pretty much gets rid of the whole things. Some applications like PyCharm may remember that it was once there, but other than that, that's the virtual environment gone.

Installing Multiple Versions of a Package with Pip