spaCy: `ValueError` after upgrade from spacy 2.3.5 to spacy 3.0.1

How to reproduce the problem

  • Create a virtualenv and install numpy==1.16.3, spacy==2.3.5 using pip 21.0 with --no-binary :all: on Debian
  • Update spacy to the latest version: pip install -U spacy --no-binary :all:
  • Start python -m spacy download nl_core_news_lg
(env) bastb@bastb-vps:/var/www/brownpapersession/dev/brownpapersession$ python -m spacy download en_core_web_trf
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/runpy.py", line 183, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/local/lib/python3.7/runpy.py", line 142, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/local/lib/python3.7/runpy.py", line 109, in _get_module_details
    __import__(pkg_name)
  File "/var/www/brwnppr/dev/env/lib/python3.7/site-packages/spacy/__init__.py", line 10, in <module>
    from thinc.api import prefer_gpu, require_gpu, require_cpu  # noqa: F401
  File "/var/www/brwnppr/dev/env/lib/python3.7/site-packages/thinc/api.py", line 2, in <module>
    from .initializers import normal_init, uniform_init, glorot_uniform_init, zero_init
  File "/var/www/brwnppr/dev/env/lib/python3.7/site-packages/thinc/initializers.py", line 4, in <module>
    from .backends import Ops
  File "/var/www/brwnppr/dev/env/lib/python3.7/site-packages/thinc/backends/__init__.py", line 7, in <module>
    from .cupy_ops import CupyOps, has_cupy
  File "/var/www/brwnppr/dev/env/lib/python3.7/site-packages/thinc/backends/cupy_ops.py", line 18, in <module>
    from .numpy_ops import NumpyOps
  File "thinc/backends/numpy_ops.pyx", line 1, in init thinc.backends.numpy_ops
ValueError: numpy.ndarray size changed, may indicate binary incompatibility. Expected 88 from C header, got 80 from PyObject

I tried reinstalling numpy==1.16.3, but that doesn’t fix the issue. The error remains the same.

Your Environment

  • Operating System: Debian 10.7
  • Python Version Used: Python 3.7.9
  • spaCy Version Used: spacy==3.0.1
  • Environment Information:
    • packages installed using pip --no-binary :all:
    • latest version of pip
    • pip debug:

[GCC 8.3.0] sys.executable: /var/www/brwnppr/dev/env/bin/python3.7 sys.getdefaultencoding: utf-8 sys.getfilesystemencoding: utf-8 locale.getpreferredencoding: UTF-8 sys.platform: linux sys.implementation: name: cpython ‘cert’ config value: Not specified REQUESTS_CA_BUNDLE: None CURL_CA_BUNDLE: None pip._vendor.certifi.where(): /var/www/brwnppr/dev/env/lib/python3.7/site-packages/pip/_vendor/certifi/cacert.pem pip._vendor.DEBUNDLED: False vendored library versions: appdirs==1.4.4 CacheControl==0.12.6 colorama==0.4.4 contextlib2==0.6.0.post1 (Unable to locate actual module version, using vendor.txt specified version) distlib==0.3.1 distro==1.5.0 (Unable to locate actual module version, using vendor.txt specified version) html5lib==1.1 msgpack==1.0.2 (Unable to locate actual module version, using vendor.txt specified version) packaging==20.8 pep517==0.9.1 progress==1.5 pyparsing==2.4.7 requests==2.25.1 certifi==2020.12.05 chardet==4.0.0 idna==2.10 urllib3==1.26.2 resolvelib==0.5.4 retrying==1.3.3 (Unable to locate actual module version, using vendor.txt specified version) setuptools==44.0.0 (Unable to locate actual module version, using vendor.txt specified version) six==1.15.0 toml==0.10.2 webencodings==0.5.1 (Unable to locate actual module version, using vendor.txt specified version)


`python -m spacy download nl_core_news_lg` works after updating to `numpy==1.20.0`

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 19 (4 by maintainers)

Most upvoted comments

If you can, the easiest solution is to upgrade numpy in your venv. It shouldn’t make a difference whether you are installing spacy==2.3.5 or spacy==3.0.1 or upgrading. An older source install of 2.3.5 should continue to work, but if you remove and reinstall, then you’ll see the same problem.

If you need a particular numpy version, the best workaround I’ve found (which I can’t find much documentation for, so I’m a little hesitant to recommend) is to provide additional constraints from your venv to pip with a constraint file as the env variable PIP_CONSTRAINT. As an example, you could use our build constraints:

PIP_CONSTRAINT="https://raw.githubusercontent.com/explosion/spaCy/master/build-constraints.txt" pip install spacy --no-binary :all:

Or you can use your own file instead with the exact version of numpy you need for your venv. The format is exactly the same as a requirements.txt file. And very confusingly, this does not do the same thing as pip install -c, which just constrains the versions of the packages that you’re trying to install, not additional build dependencies.

In general, this is a frustrating problem related to PEP 517 and build isolation, which is going to crop up for more people now because of the changes in numpy>=1.20.0. We’ve updated all our sdists over the last year so that pip install builds packages in an isolated environment by default, and right now our sdists only constrain the lower version of numpy, so by default it builds with the newest version available. This means that spacy gets compiled against the newest version of numpy in the isolated env rather than the version of numpy in your runtime env. If the runtime numpy is incompatible with the isolated numpy, you get this kind of error.

We may have to do something like adding oldest-supported-numpy to pyproject.toml, but I’m not 100% sure we want to force these versions on everyone compiling the package, since the constraints kind of explode across architectures / python versions in a way that’s really hard to maintain and in the end it’s not an issue of actual incompatibility. We can’t know which numpy constraints you have in your venv due to other packages, so it doesn’t always make sense for us to constrain things artificially on our end.

We do use our build constraints from build-constraints.txt when we build our binary wheels for pypi with multibuild so that we guarantee that our wheels are compatible with all numpy wheels on pypi.