Python 3.5 wheels on pypi

[matthew-brett]

I noticed the comment on the announcement that "pypi is not accepting 3.5 wheels".

I've uploaded quite a few 3.5 wheels to pypi in the last couple of weeks, e.g.:

https://pypi.python.org/pypi/scipy
https://pypi.python.org/pypi/matplotlib
https://pypi.python.org/pypi/Cython

Do you have any more information on that problem?

[jreback]

did you tag them?

I can certainly upload them, but was unsure

[jreback]

their is no option for the python version

[jreback]

I get this

Error processing form

Python version is required for binary distribution uploads

[jreback]

https://bitbucket.org/pypa/pypi/issues/341/no-python35-version-available-in-file

[matthew-brett]

Ah - I always upload via twine. Does that work?

[jreback]

ok that did the trick, though they are listed as cp35 for the version.....is that ok?

[jreback]

I don't think pip install works correctly doing this (for 3.5). can you verify?

[matthew-brett]

I'm not sure what role the displayed versions play on the pypi web page. I'm tempted to believe that it doesn't matter to pip, that should only care about the filename. The wheel does install correctly on my machine.

[jreback]

so pip install pandas works on 3.5 for you?

[matthew-brett]

Right - I just did that on my laptop from home, and it picked up the pypi wheel and installed it.

I think that must be generally true, because all the twine uploads I have done give their versions as cp on the web page, but work correctly.

[jreback]

ok, this works on windows. but on macosx its installing from the tar.gz, NOT the wheel?

[matthew-brett]

Hum - you're not on conda are you? It won't work from conda because it has an ancient OSX distutils platform.

[matthew-brett]

Here's me on a Python.org Python 3.5:

$ pip install pandas
Collecting pandas
  Downloading pandas-0.17.0-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl (8.8MB)
    100% |████████████████████████████████| 8.8MB 47kB/s 
Collecting pytz>=2011k (from pandas)
  Using cached pytz-2015.6-py2.py3-none-any.whl
Collecting python-dateutil>=2 (from pandas)
  Using cached python_dateutil-2.4.2-py2.py3-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): numpy>=1.7.0 in /Users/mb312/.virtualenvs/py35/lib/python3.5/site-packages (from pandas)
Requirement already satisfied (use --upgrade to upgrade): six>=1.5 in /Users/mb312/.virtualenvs/py35/lib/python3.5/site-packages (from python-dateutil>=2->pandas)
Installing collected packages: pytz, python-dateutil, pandas
Successfully installed pandas-0.17.0 python-dateutil-2.4.2 pytz-2015.6

[jreback]

I use conda for everything, so testing this I create a seaparate env.

this install with wheel works on windows (but of course numpy doesn't have a wheel so it tries to compile).

[jreback]

hmm ok then. thanks for the help!.

[matthew-brett]

Right - but conda has a distutils platform tag of something like macosx_10_5_x86_64 as I recall. The wheels are built with Python.org Python and are dual arch, and will work for everything of vintage 10.6 or newer, including system Python, Python.org Python, homebrew, macports. But running in conda pip identifies that the platform on which the wheels are built uses a more modern SDK (10.6) than the Python in which they are being installed (10.5 SDK) and therefore defaults back to the source install. This is so for any Python version.