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.5using 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:-
- packages installed using
[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)
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.5orspacy==3.0.1or 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: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.txtfile. And very confusingly, this does not do the same thing aspip 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 thatpip installbuilds 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 thatspacygets 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-numpytopyproject.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.txtwhen we build our binary wheels for pypi withmultibuildso that we guarantee that our wheels are compatible with all numpy wheels on pypi.