The python function returning just the package version in a machine-readable format:
from importlib.metadata import version
version('numpy')
Prior to python 3.8:
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 '==' {'print $2'} | tr -d '\n'" %(pkg_name)
return(subprocess.check_output(bash_str, shell=True).decode())
Sample usage:
# 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