Mac install failing

Purchased a personal license. Have several hours invested in this and have run out of things to try.

  • Installing on a Mac OS X El Capitan Version 10.11.6 Python 3.6.4
  • Created a new Anaconda environment: prodigyenv
  • Created a new directory in the Users/myname folder and added the PRODIGY_LICENSE pdf file and prodigy-1.2.0-cp35.cp36-cp35m.cp36m-macosx_10_13_x86_64.whl
  • Activated the environment and executed conda install pip; as expected got the message "All requested packages already installed.”
  • Navigated to the directory where the Prodigy files were copied.
  • Executed conda install spacy Installation was successful
  • Executed pip install prodigy.whl* Result was the message "prodigy-1.2.0-cp35.cp36-cp35m.cp36m-macosx_10_13_x86_64.whl is not a supported wheel on this platform.”
  • Executed distutils.util.get_platform() and changed the name of the wheel file accordingly toprodigy-1.2.0-cp35.cp36-cp35m.cp36m-macosx-10.6-x86_64.whl
  • Executed pip install prodigy.whl* again and now I get the message: "Requirement 'prodigy*.whl' looks like a filename, but the file does not exist prodigy*.whl is not a valid wheel filename."
  • Changed the file extension to zip and decompressed it.
  • Navigated to the Prodigy package folder and executed pip install prodigy. Got "Collecting prodigy Could not find a version that satisfies the requirement prodigy (from versions: ) No matching distribution found for prodigy"

Sorry for the trouble! The mysteries of Python packaging :frowning:

You’ve done a lot of the steps I would have suggested. One thing to try: pip install really doesn’t do anything special with a wheel file — it just needs to put the directory somewhere you can import it. So if the problem turns out to be with pip, you’ll be able to unzip the folder and just place it in your site-packages. You could then try python -m prodigy

If the library can be imported and run, then there must be some way to “convince” pip to install the file, e.g. by renaming it. On the other hand, if there’s really an incompatibility, you’ll see something like a missing symbol error.

The following should work:

python --version # Check 'pythn' is resolving to python3.5 or python3.6
unzip prodigy-1.2.0-cp35.cp36-cp35m.cp36m-macosx_10_13_x86_64.whl
PYTHONPATH=`pwd` python -m prodigy

Thanks. I simply copied the package into my anaconda virtual environment site-packages folder and confirmed that I could import the package into a PyCharm py file. That seems to work. Next I ran the python -m prodigy command and it ran up until the mmh3 import then threw a ModuleNotFoundError: No module named ‘mmh3’

Fixed this with pip install murmurhash3 then hit a snag with peewee. Takeaway from this is that there are probably other packages I need to install before I can get Prodigy to work. I will devote some time to that task and provide a status asap.

1 Like

OK, success, at least as far as successfully executing python -m prodigy

Looking forward to exploring Prodigy.

Great! Will investigate why the installer didn’t work.

For ease of reference (e.g. for others finding this thread), here’s the list of requirements. They can be installed all at once by saving this to a file and running pip install -r.

spacy>=2.0.5,<2.1.0
thinc>=6.10.2,<6.11.0
hug>=2.2.0,<3.0.0
hug-middleware-cors>=1.0.0,<2.0.0
waitress>=1.0.2,<2.0.0
plac>=0.9.6,<1.0.0
ujson>=1.35,<2.0.0
toolz>=0.8.2,<=1.0.0
requests>=2.0.0,<3.0.0
peewee>=2.10.1,<3.0.0
mmh3>=2.4,<3.0
1 Like

UPDATE: User fail. There was a typo in my re-named wheel file. Once that was corrected the pip install prodigy.whl* command worked. My apologies.

Gary,

I got an error when using:

pip install prodigy.whl*

To solve the problem I did the following:

python -c "import distutils.util; print(distutils.util.get_platform())"

I updated the .whl file from:

prodigy-1.2.0-cp35.cp36-cp35m.cp36m-macosx_10_13_x86_64.whl

to:

prodigy-1.2.0-cp35.cp36-cp35m.cp36m-macosx_10_7_x86_64.whl

then I ran:

pip install prodigy*.whl

And now I'm up and running. :smile:

3 Likes

Thanks – this worked for me. Would be great to have a more flexible install option for teams with various versions / flavors of OS.

I had a similar issue today with my macosx install (… is not a supported wheel on this platform). After running distutils.util.get_platform() I got macosx-10.6-intel

Renamed the wheel file, then the following command worked:

pip install prodigy-1.4.2-cp35.cp36-cp35m.cp36m-macosx_10_6_intel.whl

Thanks for updating with your solutions and sorry that the installation process hasn’t been as smooth as it should be.

We’ve wanted to ship the Prodigy library in a format that’s as transparent and as close to the original package as possible, so we’ve tried to avoid wrapping it in an installer. A wheel file seemed like the best option – but adding X versions of the same file with different names also felt counterproductive.

One idea would be to provide a simple shell script with Prodigy that gets the platform string and performs the necessary compatibility checks and renaming if necessary.

I am also having a few problems with my install. I have both Python 2.7 and 3.6 installed which may be creating a problem. I updated the filename to the version of get_platform that was returned with Python 3.6.5. Any thoughts on how I should address this?

jdalgliesh-C02T99LRGTFM:prodigy jdalgliesh$ python3
Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 05:52:31) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils.util
>>> print(distutils.util.get_platform())
macosx-10.9-x86_64
>>> exit()
jdalgliesh-C02T99LRGTFM:prodigy jdalgliesh$ ls
prodigy-1.4.2-cp35.cp36-cp35m.cp36m-macosx-10.9-x86_64.whl
jdalgliesh-C02T99LRGTFM:prodigy jdalgliesh$ pip3 install prodigy-1.4.2-cp35.cp36-cp35m.cp36m-macosx-10.9-x86_64.whl 
prodigy-1.4.2-cp35.cp36-cp35m.cp36m-macosx-10.9-x86_64.whl is not a supported wheel on this platform.
jdalgliesh-C02T99LRGTFM:prodigy jdalgliesh$ python
Python 2.7.13 |Anaconda 4.4.0 (x86_64)| (default, Dec 20 2016, 23:05:08) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>> import distutils.util
>>> print(distutils.util.get_platform())
macosx-10.7-x86_64
>>> exit()

@maplebay That’s interesting! For Prodigy, you definitely want to be using Python 3.6.5. (Prodigy itself is only compatible with Python 3 – but if you’re using spaCy, all models are cross-compatible, so you can use models trained with Python 3 Prodigy in Python 2 spaCy, and vice versa.)

Any thoughts on how to get past the error I am seeing?

prodigy-1.4.2-cp35.cp36-cp35m.cp36m-macosx-10.9-x86_64.whl is not a supported wheel on this platform.

@maplebay Oh sorry, I missed that part of your post!

Could you try renaming the file to ...-macosx_10_9_x86_64.whl (with underscores instead of hyphens and periods)? I think pip cares about all of those specifics, unfortunately.

(Btw, shell script for automated renaming is definitely on our list now!)

Excellent, thanks that was the problem. (the dashes and periods)

1 Like

I’m having this issue as well. I think a wrapper sounds like a good idea. I managed to solve the issue by installing an earlier version of Prodigy, which seems odd.

Yeah, that's strange – you should always be able to upgrade Prodigy to use newer features. Could you share more info on what went wrong, and the names of the Prodigy wheel files?

We just found out that if you have Mac OS 10.12, you need to rename the wheel file accordingly. It is good to go for 10.13.

Where to get the unzip file of prodigy? For me, installation through pip gave this error:
Requirement ‘prodigy-1.4.2-cp35.cp36-cp35m.cp36m-macosx_10_7_X86_64.whl’ looks like a filename, but the file does not exist
prodigy-1.4.2-cp35.cp36-cp35m.cp36m-macosx_10_7_X86_64.whl is not a supported wheel on this platform.

Did you download the correct file when you ordered Prodigy, and can you verify that it's at the right location? The "looks like a filename, but the file does not exist" usually means that pip can't even locate the .whl file you're pointing it to.