How can I update xarray? I tried:
>>> import xarray
>>> xarray.show_versions
<function show_versions at 0x7fcfaf2aa820>
But I cannot find any documentation how to read this, or how to update to a new version of xarray.
I was not the person to install it on the computer, so I do not know if it was through anaconda or something else. Is there a way to find this out?
xarray.show_versions is a function, which prints the versions of xarray and its dependencies.
To get just the version of xarray, you can check the __version__ property of the module.
Updating xarray is best done with pip or conda, depending on how you installed it in the first place.
import xarray as xr
print(xr.__version__)
# '0.18.2'
xr.show_versions()
INSTALLED VERSIONS
------------------
commit: None
python: 3.8.8 (default, Feb 19 2021, 18:07:06)
[GCC 8.3.0]
python-bits: 64
OS: Linux
OS-release: 5.11.0-27-generic
machine: x86_64
processor:
byteorder: little
LC_ALL: C.UTF-8
LANG: C.UTF-8
LOCALE: ('en_US', 'UTF-8')
libhdf5: 1.12.0
libnetcdf: 4.7.4
xarray: 0.18.2
pandas: 1.2.4
numpy: 1.20.3
scipy: 1.6.3
netCDF4: 1.5.6
pydap: None
h5netcdf: None
h5py: None
Nio: None
zarr: 2.8.3
cftime: 1.5.0
nc_time_axis: None
PseudoNetCDF: None
rasterio: 1.2.3
cfgrib: None
iris: None
bottleneck: 1.3.2
dask: 2021.05.0
distributed: 2021.05.0
matplotlib: 3.4.2
cartopy: None
seaborn: None
numbagg: None
pint: None
setuptools: 53.0.0
pip: 21.1.1
conda: None
pytest: None
IPython: 7.23.1
sphinx: None
To update xarray:
pip install --upgrade xarray
or
conda update xarray
To see if it was installed using conda or pip, run conda list xarray. If it was installed using pip, it should state pypi in the Channel column.
This is for those who want to do through GUI and who use software like pycharm, spyder, or other similar softwares.
SO, try finding 'python interpreter' in the settings. Most softwares shows the existing packages, current version,latest version(for example see the image of pycharm)
There is option to select the version that you want. for example there are times, when a module is in its beta phase and is not stable in usage. so, you can specify the latest stable version too. It is applicable for any module and not limited to xarray.
Related
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.
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
I just sent a pull request in pip with the enhancement Hugo Tavares said:
(specloud as example)
$ 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)
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)
Check pip-tools too : https://github.com/nvie/pip-tools
You can also install yolk and then run yolk -l which also gives some nice output. Here is what I get for my little virtualenv:
(venv)CWD> /space/vhosts/pyramid.xcode.com/venv/build/unittest
project#pyramid 43> yolk -l
Chameleon - 2.8.2 - active
Jinja2 - 2.6 - active
Mako - 0.7.0 - active
MarkupSafe - 0.15 - active
PasteDeploy - 1.5.0 - active
Pygments - 1.5 - active
Python - 2.7.3 - active development (/usr/lib/python2.7/lib-dynload)
SQLAlchemy - 0.7.6 - active
WebOb - 1.2b3 - active
account - 0.0 - active development (/space/vhosts/pyramid.xcode.com/project/account)
distribute - 0.6.19 - active
egenix-mx-base - 3.2.3 - active
ipython - 0.12 - active
logilab-astng - 0.23.1 - active
logilab-common - 0.57.1 - active
nose - 1.1.2 - active
pbkdf2 - 1.3 - active
pip - 1.0.2 - active
pyScss - 1.1.3 - active
pycrypto - 2.5 - active
pylint - 0.25.1 - active
pyramid-debugtoolbar - 1.0.1 - active
pyramid-tm - 0.4 - active
pyramid - 1.3 - active
repoze.lru - 0.5 - active
simplejson - 2.5.0 - active
transaction - 1.2.0 - active
translationstring - 1.1 - active
venusian - 1.0a3 - active
waitress - 0.8.1 - active
wsgiref - 0.1.2 - active development (/usr/lib/python2.7)
yolk - 0.4.3 - active
zope.deprecation - 3.5.1 - active
zope.interface - 3.8.0 - active
zope.sqlalchemy - 0.7 - active
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
You can use the grep command to find out.
pip show <package_name>|grep Version
Example:
pip show urllib3|grep Version
will show only the versions.
Metadata-Version: 2.0
Version: 1.12
There's also a tool called pip-check which gives you a quick overview of all installed packages and their update status:
Haven't used it myself; just stumbled upon it and this SO question in quick succession, and since it wasn't mentioned...
pip show works in python 3.7:
pip show selenium
Name: selenium
Version: 4.0.0a3
Summary: Python bindings for Selenium
Home-page: https://github.com/SeleniumHQ/selenium/
Author: UNKNOWN
Author-email: UNKNOWN
License: Apache 2.0
Location: c:\python3.7\lib\site-packages\selenium-4.0.0a3-py3.7.egg
Requires: urllib3
Required-by:
The easiest way is this:
import jinja2
print jinja2.__version__
pip list can also be told to format its output as json.
It could be a safer approach to parse the version.
pip list --no-index --format=json | \
jq -r '.[] | select(.name=="Jinja2").version'
# 2.10.1
On windows, you can issue command such as:
pip show setuptools | findstr "Version"
Output:
Version: 34.1.1
To do this using Python code:
Using importlib.metadata.version
Python ≥3.8
import importlib.metadata
importlib.metadata.version('beautifulsoup4')
'4.9.1'
Python ≤3.7
(using importlib_metadata.version)
!pip install importlib-metadata
import importlib_metadata
importlib_metadata.version('beautifulsoup4')
'4.9.1'
Using pkg_resources.Distribution
import pkg_resources
pkg_resources.get_distribution('beautifulsoup4').version
'4.9.1'
pkg_resources.get_distribution('beautifulsoup4').parsed_version
<Version('4.9.1')>
Credited to comments by sinoroc and mirekphd.
For Windows you can
open cmd and type python, press enter.
type the import and press enter.
type ._version__ and press enter.
As you can see in screen shot here I am using this method for checking the version of serial module.
In question, it is not mentioned which OS user is using (Windows/Linux/Mac)
As there are couple of answers which will work flawlessly on Mac and Linux.
Below command can be used in case the user is trying to find the version of a python package on windows.
In PowerShell use below command :
pip list | findstr <PackageName>
Example:- pip list | findstr requests
Output : requests 2.18.4
import pkg_resources
packages = [dist.project_name for dist in pkg_resources.working_set]
try:
for count, item in enumerate(packages):
print(item, pkg_resources.get_distribution(item).version)
except:
pass here
The indentations might not be perfect. The reason I am using a Try- Except block is that few library names will throw errors because of parsing the library names to process the versions. even though packages variable will contain all the libraries install in your environment.
I recently added the package typepigeon to conda-forge. On conda-forge it is currently at version 1.0.9; however, when installing typepigeon via conda install, the output of pip list shows its version to be 0.0.0.post2.dev0+a27ab2a instead of 1.0.9.
conda list:
typepigeon 1.0.9 pyhd8ed1ab_0 conda-forge
pip list:
typepigeon 0.0.0.post2.dev0+a27ab2a
I think the issue arises from the way I am assigning the version (I am using dunamai to extract the Git tag as the version number). This version extraction is done within setup.py of typepigeon.
try:
__version__ = Version.from_any_vcs().serialize()
except RuntimeError as error:
warnings.warn(f'{error.__class__.__name__} - {error}')
__version__ = '0.0.0'
When conda-forge builds the feedstock, I think it might be looking at the Git tag of the feedstock repository instead of the version from PyPI (as it is locally executing setup.py).
How can I modify the Conda Forge recipe to force the PyPI version?
I've figured out a solution; it might not be the best possible way to do this, but it works for my workflow.
I injected the version into the setup.py by looking for an environment variable (that I called __version__):
if '__version__' in os.environ:
__version__ = os.environ['__version__']
else:
from dunamai import Version
try:
__version__ = Version.from_any_vcs().serialize()
except RuntimeError as error:
warnings.warn(f'{error.__class__.__name__} - {error}')
__version__ = '0.0.0'
Then, in the conda-forge recipe, I added an environment variable (__version__) to the build step:
build:
noarch: python
script: export __version__={{ version }} && {{ PYTHON }} -m pip install . -vv
Conda wants to downgrade my blas, lapack etc. packages from an mkl to an openblas version. I understand that conda juggling with mkl versus openblas seems not an uncommon issue. Yet, I have not found a solution to do the job for me. I have these packages installed
blas 2.113 mkl conda-forge
blas-devel 3.9.0 13_linux64_mkl conda-forge
libblas 3.9.0 13_linux64_mkl conda-forge
libcblas 3.9.0 13_linux64_mkl conda-forge
liblapack 3.9.0 13_linux64_mkl conda-forge
liblapacke 3.9.0 13_linux64_mkl conda-forge
mkl 2022.0.1 h06a4308_117
mkl-devel 2022.0.1 h66538d2_117
mkl-include 2022.0.1 h06a4308_117
mkl-service 2.4.0 py39h404a4ab_0 conda-forge
mkl_fft 1.3.1 py39h6964271_2 conda-forge
mkl_random 1.2.2 py39h8b66066_1 conda-forge
and I have a .condarc (on linux) containing
channels:
- conda-forge
- defaults
dependencies:
- python>=3.6
- numpy>=1.13
- scipy>=0.18
- cython>=0.29
- mkl
- mkl-devel
- libblas=*=*mkl
- bottleneck
- pip
- setuptools>=30.3.0
- h5py
- pyyaml
- pytest
ssl_verify: true
auto_activate_base: false
Moreover in the conda-meta directories I have a pinned file, containing the line libblas=*=*mkl. Yet, upon conda update --all this is suggested:
The following packages will be DOWNGRADED:
... other pkgs ...
libblas 3.9.0-13_linux64_mkl --> 3.9.0-13_linux64_openblas
libcblas 3.9.0-13_linux64_mkl --> 3.9.0-13_linux64_openblas
liblapack 3.9.0-13_linux64_mkl --> 3.9.0-13_linux64_openblas
Why, despite of the the .condarc and pinned files, am I getting this switch from mkl to openblas, and what else can I do to prevent it?
I'm posting a quirky workaround for my own OP. This finally worked for me.
First, I could not convince conda to respect the channel ordering in .condarc nor the content in the pinned files before running the update by any other suggestion, including those found outside of stackoverflow .
Second, I stored a conda list | grep mkl, a conda list | grep intel, and a conda list | grep open away for later reference. Then I "gave in" and let the "upgrade" happen, running conda update --all. No need to mention that after that, my environment indeed showed the unwanted replacement of all mkl-type libraries with openblas stuff.
Third, and within the openblas-infested environment I "re-installed" mkl
conda install blas=*=*mkl
conda install libblas=*=*mkl
conda update numpy
conda update scipy
conda install intel-openmp # the "update" had also removed this ...
Also make sure that no openblas-stuff remains by doing a conda remove on whatever related package. (I'm not claiming that really all of the above commands are necessary to reach the original state of the environment regarding mkl. But that's what I did.)
Fourth, comparing with the reference notes from the preceding second step I checked that at this point my environment claimed to be back to "all-mkl". Moreover, using this extremely helpful site http://markus-beuckelmann.de/blog/boosting-numpy-blas.html I also checked, that this was indeed true regarding typical mkl timings to be expected.
On the side, there is a really weird and confusing issue, which may not be related to the OP but which I stumbled across in this context: On the WWW one finds many many many quotes stating, that for numpy or scipy actually "using" mkl, one has to have this kind of output
In []: numpy.show_config()
blas_mkl_info:
libraries = ['mkl_rt', 'pthread']
library_dirs = ['/home/abcd/efgh..../lib']
from numpy/scipy.show_confi(). This seems not true in general. In fact when one gets
In []: numpy.show_config()
blas_info:
libraries = ['cblas', 'blas', 'cblas', 'blas']
library_dirs = ['/home/abcd/efgh..../lib']
this is no cause for panic as long as in /home/abcd/efgh..../lib one finds everything linked as
liblapacke.so -> libmkl_rt.so.2*
libblas.so -> libmkl_rt.so.2*
...a.s.o.
which I do.
(conda is just soo painful. sigh)
The package management can be a mess whenever the Intel MKL package has been updated, but the numpy package has not. I may end up with Intel MKL being installed, but numpy is using the openblas. To get this working in my setup, I often do this when creating a new environment:
conda create -y --name test python=3 numpy mkl cmake blas=*=*mkl
so that the MKL is installed at the same time as numpy, and numpy will use the MKL. This often results in an older version of MKL, since numpy was linked against an older version of the MKL.
Without the blas=*=*mkl, I will often end up with an openblas based numpy installed with the newest version of the Intel MKL not being used by anything.
conda create -n test33 numpy mkl blas=*=*mkl
.
.
.
The following NEW packages will be INSTALLED:
blas pkgs/main/osx-64::blas-1.0-mkl
.
numpy pkgs/main/osx-64::numpy-1.21.5-py39h2e5f0a9_1
.
mkl pkgs/main/osx-64::mkl-2021.4.0-hecd8cb5_637
.
# results in:
blas_opt_info:
libraries = ['mkl_rt', 'pthread']
conda create -n test33 numpy mkl
.
.
.
The following NEW packages will be INSTALLED:
blas pkgs/main/osx-64::blas-1.0-openblas
.
numpy pkgs/main/osx-64::numpy-1.21.5-py39h9c3cb84_1
.
mkl pkgs/main/osx-64::mkl-2022.0.0-hecd8cb5_105
.
# results in:
blas_opt_info:
libraries = ['openblas', 'openblas']
Unfortunately, numpy does not appear to show the blas library it is linked against in its version id. Oftentimes, you will end up with both openblas and mkl in your environment.
See the note section at the end of https://conda-forge.org/docs/maintainer/knowledge_base.html#switching-blas-implementation
If you want to commit to a specific blas implementation, you can prevent conda from switching back by pinning the blas implementation in your environment. To commit to mkl, add blas=*=mkl to <conda-root>/envs/<env-name>/conda-meta/pinned, as described in the conda-docs.
I have python2.7.8 on mac, things I did:
sudo easy_install pip - worked.
pip install numpy:
Requirement already satisfied (use --upgrade to upgrade): numpy in /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python
I also did "pip upgrade numpy" - no luck. What's wrong?
Your problem is a conflict of different Python versions.
I would recommend installing Python and all the packages, such as numpy, scipy, matplotlib, pandas, etc via Brew
See this tutorial: https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/Homebrew-and-Python.md
You can verify which Python you're running with which python or which python3 in Terminal.
This solution is more flexible and cleaner in my opinion than using Conda/Miniconda. However it is also a bit more lengthy to install, as you need to have Xcode, devtools installed to build everything
Could it be that you have multiple versions of python installed? What happens if you run python using the full path like this:
$ /System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2
instead of just python2?
In my experience on Mac (and other OS too) it is best to go with Anaconda / Miniconda. This is especially true for packages like NumPy and others from scientific stack.
While Anaconda is a full-blown distribution with about 200 packages, Miniconda is just Python with a few basic libraries. The big advantage is that all packages install as binary. Further, it makes it very simple and stable to install multiple Python versions side by side. For example:
conda create -n py27 python=2.7
creates a new environment with Python 2.7. Activate with:
source activate py27
Now:
conda install numpy
installs NumPy cleanly.
You can do the same for Python 3.5 and switch between environments with source activate.
After jumping from one stackoverflow answer to another I found the solution!
my problems were:
numpy at different location( actually at right, expected-to-be location). It was the IDLE that looks for its own default folder where python2.7 installed.
I checked that my numpy is working like this, run this script to check it is working:
import os
import sys
import pygame
sys.path.insert(0, '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python')
import numpy
pygame.init()
print "( using __version__): " + numpy.__version__
print numpy.version.version
user_paths = os.environ['PYTHONPATH']
print(user_paths)
sys.path insertion adds additional path to IDLE, so it knows where to look for numpy.
Then I check if numpy truly imported - i just print its version. Right now it is 1.8.0rc.
I want to find a way to avoid using this syspath insertion all the time.
So far so good - for now.
I had a similiar problem with numpy. However, it was resolved by choosing the right environment. If you are using VScode, open the command palette (ctrl+shift+p) and type
Python: Select Interpreter.
From there, try choosing the right virtual environment/Interpreter.
I used this guide to install the "scientific stack" for Python (OSX 10.9.2, brewed Python 2.7.6, IPython 2.0, matplotlib 1.3.1, libpng 1.6.10). Everything was looking good.
However, trying to run a simple plot in IPython's notebook environment with --pylab=inline gives me this error:
/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/core/formatters.py:239: FormatterWarning: Exception in image/png formatter: Could not create write struct
FormatterWarning,
And in the terminal it says: libpng warning: Application built with libpng-1.5.17 but running with 1.6.10
I have no other libpng installed as far as I can tell. I tried deleting all files beginning with libpng from /usr/local/ and reinstalling everything, to no avail. The output from building matplotlib (pip install matplotlib) contains:
BUILDING MATPLOTLIB
matplotlib: yes [1.3.1]
python: yes [2.7.6 (default, Mar 16 2014, 15:04:47) [GCC
4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)]]
platform: yes [darwin]
REQUIRED DEPENDENCIES AND EXTENSIONS
numpy: yes [version 1.8.1]
dateutil: yes [using dateutil version 2.2]
tornado: yes [using tornado version 3.2]
pyparsing: yes [using pyparsing version 2.0.1]
pycxx: yes [Couldn't import. Using local copy.]
libagg: yes [pkg-config information for 'libagg' could not
be found. Using local copy.]
freetype: yes [version 17.2.11]
png: yes [version 1.6.10]
OPTIONAL SUBPACKAGES
sample_data: yes [installing]
toolkits: yes [installing]
tests: yes [using nose version 1.3.1]
OPTIONAL BACKEND EXTENSIONS
macosx: yes [installing, darwin]
qt4agg: yes [installing, Qt: 4.8.6, PyQt4: 4.10.4]
gtk3agg: no [Requires pygobject to be installed.]
gtk3cairo: no [Requires cairo to be installed.]
gtkagg: no [Requires pygtk]
tkagg: yes [installing, version 81008]
wxagg: no [requires wxPython]
gtk: no [Requires pygtk]
agg: yes [installing]
cairo: no [cairo not found]
windowing: no [Microsoft Windows only]
OPTIONAL LATEX DEPENDENCIES
dvipng: no
ghostscript: no
latex: no
pdftops: no
So it seems to me matplotlib should be compiled against libpng 1.6.10? Can someone help me figure out what's going on?
An expansion of the answer provided by #glenn-randers-pehrson:
pip uninstall matplotlib
cd /opt/X11/include/libpng15
mv png.h _png.h
mv pngconf.h _pngconf.h
mv pnglibconf.h _pnglibconf.h
pip install matplotlib
(if needed remove the old directory or use the force option)
(now move the .h files back to their original locations)
Look for old header files beginning with "png" (png.h, pngconf.h, perhaps others) and remove them.
For the sake of documentation (following on from above comments):
Remove X11
launchctl unload /Library/LaunchAgents/org.macosforge.xquartz.startx.plist
sudo launchctl unload /Library/LaunchDaemons/org.macosforge.xquartz.privileged_startx.plist
sudo rm -rf /opt/X11* /Library/Launch*/org.macosforge.xquartz.* /Applications/Utilities/XQuartz.app /etc/*paths.d/*XQuartz
sudo pkgutil --forget org.macosforge.xquartz.pkg
Then,
if you have matplotlib / python installed, run the following as appropriate:
pip uninstall matplotlib
pip uninstall ipython
Then,
pip install matplotlib
pip install ipython
If necessary, XQuartz can be re-installed from https://www.macupdate.com/app/mac/26593/xquartz.
[Note: This does re-add the /opt/X11/include/libpng15/png.h etc files, but ipython worked fine afterwards.]
While it is a bit ridiculous having multiple copies of libpng around, this problem results from the path for the pip compiler and python being different. You could also fix this problem through the path, and then recompiling, but the above solutions work too.