dear all, thanks for the beta invite approved, I had the zip downloaded not the whl as indicated from installation, any instruction on the zip installation (not working on pip install zip though)
This is strange – somehow the files are being converted to .zip when downloading them from the browser (since .whl is an archive format). This seems to be an issue with the provider we’re using for shipping the downloads – we’re working on resolving the issue with them or, alternatively, will update the docs accordingly. It’s especially weird, because it worked fine before.
In the meantime, you should be able to simply rename the file to.whl. Sorry for the inconvenience!
Thanks for the quick reply. I have change the file extension back to .whl
now, do a virtualenv with python3 and install the spacy,
and do pip install, it shows up
prodigy-0.2.0-cp36-cp36m-linux_x86_64.whl is not a supported wheel on this platform
Hm! Fix should be:
mv prodigy-0.2.0-cp36-cp36m-linux_x86_64.whl prodigy-0.2.0-cp35-cp35m-linux_x86_64.whl
It seems pip does more filename version checking than we realised. We’ve just added python3.5 support, so this is the first time this has come up.
(I’m assuming you’re trying to install with python3.5. If python3 is 3.4 or lower on your system, that’s currently not supported.)
Python 3.5.2, I was wonder whether it’s version of cp supported,
import pip; print(pip.pep425tags.get_supported())
[(‘cp35’, ‘cp35m’, ‘manylinux1_x86_64’), (‘cp35’, ‘cp35m’, ‘linux_x86_64’), (‘cp35’, ‘abi3’, ‘manylinux1_x86_64’), (‘cp35’, ‘abi3’, ‘linux_x86_64’), (‘cp35’, ‘none’, ‘manylinux1_x86_64’), (‘cp35’, ‘none’, ‘linux_x86_64’), (‘cp34’, ‘abi3’, ‘manylinux1_x86_64’), (‘cp34’, ‘abi3’, ‘linux_x86_64’), (‘cp33’, ‘abi3’, ‘manylinux1_x86_64’), (‘cp33’, ‘abi3’, ‘linux_x86_64’), (‘cp32’, ‘abi3’, ‘manylinux1_x86_64’), (‘cp32’, ‘abi3’, ‘linux_x86_64’), (‘py3’, ‘none’, ‘manylinux1_x86_64’), (‘py3’, ‘none’, ‘linux_x86_64’), (‘cp35’, ‘none’, ‘any’), (‘cp3’, ‘none’, ‘any’), (‘py35’, ‘none’, ‘any’), (‘py3’, ‘none’, ‘any’), (‘py34’, ‘none’, ‘any’), (‘py33’, ‘none’, ‘any’), (‘py32’, ‘none’, ‘any’), (‘py31’, ‘none’, ‘any’), (‘py30’, ‘none’, ‘any’)]
try rename it, still complain as not supported
What did you rename to? Was just editing my reply when you replied…
renamed to prodigy-0.2.0-cp35-cp36m-linux_x86_64.whl, while at the meantime, upgrade to python3.6 seems to do the trick,
pip install proceed (but with some reds, I need to take a look at these), thanks for the quick help here (and firefox didn’t screw up the whl to zip)
Aha, yes -- you got in just while I was editing! correct filename is prodigy-0.2.0-cp35-cp35m-linux_x86_64.whl
Thanks, confirmed rename to all 35 worked perfectly under 35 virtualenv.
1 Like
Btw, I think we figured out the underlying issue and it will hopefully be fixed by our download provider asap.
It looks like it’s related to the MIME type set on the file when it’s requested and served. The file on the server has the correct extension .whl, but its MIME type was changed to application/zip. (The correct MIME type should be application/octet-stream and we’ve verified that the files we uploaded had it set.)
2 Likes
Hi - I ran into the same set of problems on Mac today. I upgraded my Python to 3.6, but it tells me (after renaming the zip to .whl) that this is not a supported wheel on this platform:
pip install prodigy-0.2.0-cp36-cp36m-macosx_10_12_x86_64.whl
prodigy-0.2.0-cp36-cp36m-macosx_10_12_x86_64.whl is not a supported wheel on this platform.
Ideas?
I ran into the same issue. Renaming the .zip to a .whl and installing in a virtual environment where python was upgraded to v3.6 solved it for me. Unfortunately, along the way, as I tried different approaches, I used up all of my group’s installs. 
Is it possible to get a supplement of more installs allotted to us?
Sure, just reset your downloads! Sorry about the inconvenience – we're still working on the best solution for providing all the wheels and managing the downloads. Hopefully, this will all be much easier with the next release 
Hm. If you do pip --version, what do you see?
I’m just trying to make sure the pip you’re running is actually the Python 3.6 pip — it’s possible the correct one was mapped to like pip3? I get tripped up by this sort of thing all the time.
If pip refers to the correct Python version, I wonder whether the wheel is paying attention to the OSX 10_12 part? What OSX version are you on? Maybe rename for that?
At that worked, Matt – thanks, don’t know why I didn’t think of it 
(I’m on 10.11 not 12.)
1 Like
Updated our download process for the latest version (v0.2.1) so the whl-to-zip problem shouldn’t be happening anymore 
If you do end up hitting the “… is not a supported wheel on this platform” error message try one of the following:
- Update pip to the latest version. I came across this issue in a new test environment and it turned out that upgrading from pip 7.x to 9.x solved it, as the new version seems to include more backwards compatibility checks.
- Try renaming the file to match your platform (you can check this via
distutils.util.get_platform()for example). For more details on how wheel filenames work in Python, see this article.