I am facing two different errors while installing & importing Prodigy. The first one is the same as the one given in Installation file:
is not a supported wheel on this platform
I was able to solve this problem through the method given in file. i.e. By changing the file name to
prodigy-1.3.0-cp35.cp36-cp35m.cp36m-win32.whl
Then while importing prodigy, I am facing the below error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Python_3-6-4\prodigy\__init__.py", line 4, in <module>
from . import recipes # noqa
File "C:\Python_3-6-4\prodigy\recipes\__init__.py", line 4, in <module>
from . import ner, textcat, pos, compare, terms, generic # noqa
File "C:\Python_3-6-4\prodigy\recipes\ner.py", line 16, in <module>
from ..components.preprocess import split_sentences, add_tokens
ImportError: cannot import name 'add_tokens'
Prodigy only works on 64 bit versions of Python — the limitation’s in spaCy, but it’s fairly hard to fix, because of the different unicode representations in 32 bit Windows Python builds.
Once you have your 64 bit Python 3.6, you should run a command like C:\Python64\bin\python -m venv64. This will create you a virtualenv directory venv64. You can then run venv64\Scripts\activate. After that, when you write python, it should run the 64 bit version you just installed. Then run python -m pip install /path/to/prodigy.whl. When you want to return your shell to the previous state, run deactivate. If you’re executing from a script instead of running things interactively, I usually prefer to execute the Python inside the virtualenv directly, e.g. venv64/bin/python -m prodigy will run the copy of Prodigy installed within that virtual environment.
The virtual environments give you explicit control of which version of Python is being executed. Without this, you can run pip to install something, but the version of pip being executed might refer to the wrong version of Python. The resulting errors are often confusing. (This happens to me and pretty much every other Python developer I know at least once a week…)
Hmm, I’m not sure why the path isn’t being updated — I’m not very familiar with Windows development unfortunately.
Can you execute the virtualenv’s Python explicitly? Like say your virtualenv is at C:\nlp\venv, you should be able to write C:\nlp\venv\Scripts\python -m prodigy?
Alternatively you might be able to run just prodigy, or C:\nlp\venv\Scripts\prodigy
