astropy: Error: cannot import name 'soft_unicode' from 'markupsafe' (v4.3)

Description

Using pip install astropy==4.3 (or having astropy==4.3 in the requirements.txt file for a package dependent on astropy) errors when “Getting requirements to build wheel”.

Expected behavior

Successful installation of astropy v4.3

Actual behavior

Installation fails.
The error thrown is

ImportError: cannot import name 'soft_unicode' from 'markupsafe'

The root cause is described here.

Steps to Reproduce

pip install astropy==4.3

(Note 4.2.1) suffers same affliction, as do others, presumably. 5.0.4 installs fine, of course.

System Details

import platform; print(platform.platform()) Windows-10-10.0.22000-SP0 import sys; print(“Python”, sys.version) Python 3.10.4 (tags/v3.10.4:9d38120, Mar 23 2022, 23:13:41) [MSC v.1929 64 bit (AMD64)] import numpy; print(“Numpy”, numpy.version) Numpy 1.22.3 import erfa; print(“pyerfa”, erfa.version) pyerfa 2.0.0.1 import astropy; print(“astropy”, astropy.version) astropy 5.0.4 import scipy; print(“Scipy”, scipy.version) Traceback (most recent call last): File “<stdin>”, line 1, in <module> ModuleNotFoundError: No module named ‘scipy’ import matplotlib; print(“Matplotlib”, matplotlib.version) Traceback (most recent call last): File “<stdin>”, line 1, in <module> ModuleNotFoundError: No module named ‘matplotlib’

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 24 (19 by maintainers)

Links to this issue

python - Error while trying to install Astropy 4.3 'ImportError: cannot import name 'soft_unicode' from 'markupsafe'' - Stack Overflow

Most upvoted comments

Shouldn’t using pip without build-system isolation be the fix here? Instead of astropy making a release for a no-longer supported version for a problem in jinja2.

So this should work:

# install astropy build deps into env first:
$ pip install setuptools setuptools_scm wheel cython==0.29.22 jinja2==2.10.3 numpy markupsafe==2.0.1 extension-helpers
$ pip install --no-build-isolation astropy==4.3.1

maxnoe on Jan 26, 2023

It seems the default pip version on debian buster (18.x) is too old to recognize the tags in that wheel. Updating pip solves it and installs the wheel on buster.

However, the workaround above (–no-build-isolation) makes the build work also with debian buster’s package manager version of pip.

So you have two options that work without a new astropy release / wheel build

Update pip to make the wheel installable
Use --no-build-isolation with the package manager provided version of pip

$ docker run --rm -it debian:buster bash 
# apt update
# apt install python3 python3-pip python3-venv
# python3 -m venv venv
# source venv/bin/activate
# pip --version
pip 18.1 from /venv/lib/python3.7/site-packages/pip (python 3.7)
# pip install astropy==4.3.1  # tries to download and build source, fails due to this issue
# pip install -U pip
# pip --version
pip 22.3.1 from /venv/lib/python3.7/site-packages/pip (python 3.7)
# pip install astropy==4.3.1 # downloads wheel 
Collecting astropy==4.3.1
  Downloading astropy-4.3.1-cp37-cp37m-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (10.7 MB)

I checked, and the workaround above for mac also works on debian with the old pip, but the preferred version would be to use the current pip which then installs the wheel (also for numpy!)

maxnoe on Jan 30, 2023

I think the main conclusion I get from this is that we should not add dependencies to astropy unless they are really essential. In the end, they just cause trouble. And that includes build dependencies.

mhvk on Jan 30, 2023

I can confirm that first updating pip solves my issue here; so for me the problem is resolved. Thank you for the help.

olebole on Jan 30, 2023

I have basically the same problem, as in one of our environments the Python version is fixed to 3.7 (despite EOL this year). Even a requirements.txt

MarkupSafe ==2.0.1
jinja2     ==2.10.3
astropy    ==4.3.1

doesn’t work, as jinja2 pulls the most actual version of markupsafe.

olebole on Jan 26, 2023