Find which version of package is installed with pip
Using pip, is it possible to figure out which version of a package is currently installed? I know about pip install XYZ —upgrade but I am wondering if there is anything like pip info XYZ . If not what would be the best way to tell what version I am currently using.
16 Answers 16
As of pip 1.3, there is a pip show command.
$ pip show Jinja2 --- Name: Jinja2 Version: 2.7.3 Location: /path/to/virtualenv/lib/python2.7/site-packages Requires: markupsafe In older versions, pip freeze and grep should do the job nicely.
$ pip freeze | grep Jinja2 Jinja2==2.7.3 The naming of ‘freeze’ is historical — it dates back to at least 2008. At the time, many people were already familiar with «freezing» ruby gems, so pip borrowed the then-widely-used name.
this was not obvious nor documented, but you can type pip show pip to get pip’s version info, rather than pip —version as I would’ve expected.
I would suggest calling with -i flag as you sometimes do not know which ones are capital letters and which ones are not: pip freeze | grep -i xyz
I just sent a pull request in pip with the enhancement Hugo Tavares said:
$ pip show specloud Package: specloud Version: 0.4.4 Requires: nose figleaf pinocchio Pip 1.3 now also has a list command:
$ pip list argparse (1.2.1) pip (1.5.1) setuptools (2.1) wsgiref (0.1.2) Say package name is X. To find the version — What is the difference between using pip list and doing import X and then X.__version__? Are both the package versions?
both are valid, but pip list is generic, and __version__ is not. I have also seen version() and get_version() for the imported one.
and with —outdated as an extra argument, you will get the Current and Latest versions of the packages you are using :
$ pip list --outdated distribute (Current: 0.6.34 Latest: 0.7.3) django-bootstrap3 (Current: 1.1.0 Latest: 4.3.0) Django (Current: 1.5.4 Latest: 1.6.4) Jinja2 (Current: 2.6 Latest: 2.8) So combining with AdamKG ‘s answer :
$ pip list --outdated | grep Jinja2 Jinja2 (Current: 2.6 Latest: 2.8) An interesting option. I’d rather have it list all of them, and let me know if any of them are outdated, though.
The python function returning just the package version in a machine-readable format:
from importlib.metadata import version version('numpy') pip install importlib-metadata from importlib_metadata import version version('numpy') The bash equivalent (here also invoked from python) would be much more complex (but more robust — see caution below):
import subprocess def get_installed_ver(pkg_name): bash_str="pip freeze | grep -w %s= | awk -F '==' | tr -d '\n'" %(pkg_name) return(subprocess.check_output(bash_str, shell=True).decode()) # pkg_name="xgboost" # pkg_name="Flask" # pkg_name="Flask-Caching" pkg_name="scikit-learn" print(get_installed_ver(pkg_name)) >>> 0.22 Note that in both cases pkg_name parameter should contain package name in the format as returned by pip freeze and not as used during import , e.g. scikit-learn not sklearn or Flask-Caching , not flask_caching .
Note that while invoking pip freeze in bash version may seem inefficient, only this method proves to be sufficiently robust to package naming peculiarities and inconsistencies (e.g. underscores vs dashes, small vs large caps, and abbreviations such as sklearn vs scikit-learn ).
Caution: in complex environments both variants can return surprise version numbers, inconsistent with what you can actually get during import .
One such problem arises when there are other versions of the package hidden in a user site-packages subfolder. As an illustration of the perils of using version() here’s a situation I encountered:
$ pip freeze | grep lightgbm lightgbm==2.3.1 and $ python -c "import lightgbm; print(lightgbm.__version__)" 2.3.1 vs. $ python -c "from importlib_metadata import version; print(version(\"lightgbm\"))" 2.2.3 until you delete the subfolder with the old version (here 2.2.3) from the user folder (only one would normally be preserved by `pip` - the one installed as last with the `--user` switch): $ ls /home/jovyan/.local/lib/python3.7/site-packages/lightgbm* /home/jovyan/.local/lib/python3.7/site-packages/lightgbm-2.2.3.dist-info /home/jovyan/.local/lib/python3.7/site-packages/lightgbm-2.3.1.dist-info Another problem is having some conda-installed packages in the same environment. If they share dependencies with your pip-installed packages, and versions of these dependencies differ, you may get downgrades of your pip-installed dependencies.
To illustrate, the latest version of numpy available in PyPI on 04-01-2020 was 1.18.0, while at the same time Anaconda’s conda-forge channel had only 1.17.3 version on numpy as their latest. So when you installed a basemap package with conda (as second), your previously pip-installed numpy would get downgraded by conda to 1.17.3, and version 1.18.0 would become unavailable to the import function. In this case version() would be right, and pip freeze / conda list wrong:
$ python -c "from importlib_metadata import version; print(version(\"numpy\"))" 1.17.3 $ python -c "import numpy; print(numpy.__version__)" 1.17.3 $ pip freeze | grep numpy numpy==1.18.0 $ conda list | grep numpy numpy 1.18.0 pypi_0 pypi Checking a Python module version at runtime
Many third-party Python modules have an attribute which holds the version information for the module (usually something like module.VERSION or module.__version__ ), however some do not. Particular examples of such modules are libxslt and libxml2. I need to check that the correct version of these modules are being used at runtime. Is there a way to do this? A potential solution wold be to read in the source at runtime, hash it, and then compare it to the hash of the known version, but that’s nasty. Is there a better solutions?
7 Answers 7
Use pkg_resources. Anything installed from PyPI at least should have a version number.
>>> import pkg_resources >>> pkg_resources.get_distribution("blogofile").version '0.7.1' Also note that, package name must be that of PyPI entry. So something like «pkg_resources.get_distribution(‘MySQLdb’).version» won’t work but «pkg_resources.get_distribution(‘mysql-python’).version» will.
If you are running with an absolute file name, pkg_resources might pick up a different version shadowing the one you are actually running because it has higher precedence on your PYTHONPATH or similar.
In case somebody wants to know how to make the __version__ attribute: stackoverflow.com/q/17583443/562769
If you’re on python >=3.8 you can use a module from the built-in library for that. To check a package’s version (in this example lxml ) run:
>>> from importlib.metadata import version >>> version('lxml') '4.3.1' This functionality has been ported to older versions of python (
pip install importlib_metadata and then to check a package’s version (in this example lxml ) run:
>>> from importlib_metadata import version >>> version('lxml') '4.3.1' Keep in mind that this works only for packages installed from PyPI. Also, you must pass a package name as an argument to the version method, rather than a module name that this package provides (although they’re usually the same).
I’d stay away from hashing. The version of libxslt being used might contain some type of patch that doesn’t effect your use of it.
As an alternative, I’d like to suggest that you don’t check at run time (don’t know if that’s a hard requirement or not). For the python stuff I write that has external dependencies (3rd party libraries), I write a script that users can run to check their python install to see if the appropriate versions of modules are installed.
For the modules that don’t have a defined ‘version’ attribute, you can inspect the interfaces it contains (classes and methods) and see if they match the interface they expect. Then in the actual code that you’re working on, assume that the 3rd party modules have the interface you expect.