I don't think it's the sorting, per se. All of the get_supported() tags are 10.5 or earlier. Here's the output: https://gist.github.com/rmcgibbo/1d0f5d166ca48253b5a9 On Fri, Nov 6, 2015 at 11:00 AM, Daniel Holth wrote:

It should already be sorted. Try python -c "import pprint, pip.pep425tags; pprint.pprint(pip.pep425tags.get_supported())"

Do none of the tags for the available numpy wheels appear in that list?

On Fri, Nov 6, 2015 at 1:48 PM Robert McGibbon wrote:

...

Hi,

I just tried to run `pip install numpy` on my OS X 10.10.3 box, and it proceeds to download and compile the tarball from PyPI from source (very slow). I see, however, that pre-compiled OS X wheel files are available on PyPI for OS X 10.6 and later.

Checking the code, it looks like pip is picking up the platform tag through `distutils.util.get_platform()`, which returns 'macosx-10.5-x86_64' on this machine. At root, I think this comes from the MACOSX_DEPLOYMENT_TARGET=10.5 entry in the Makefile at `python3.5/config-3.5m/Makefile`. I know that this value is used by distutils compiling python extension modules -- presumably so that they can be distributed to any target machine with OS X >=10.5 -- so that's good. But is this the right thing for pip to be using when checking whether a binary wheel is compatible? I see it mentioned https://www.python.org/dev/peps/pep-0425/#id13 in PEP 425, so perhaps this was already hashed out on the list.

Best, Robert _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

For OS X, the pip get_platform function eventually calls into here: https://github.com/python/cpython/blob/master/Lib/_osx_support.py#L429-L439, and I think the comment kind of explains the bug. -Robert On Fri, Nov 6, 2015 at 11:10 AM, Daniel Holth wrote:

I see what you mean. Sounds like a bug to me.

On Fri, Nov 6, 2015 at 2:07 PM Robert McGibbon wrote:

...

I don't think it's the sorting, per se. All of the get_supported() tags are 10.5 or earlier. Here's the output: https://gist.github.com/rmcgibbo/1d0f5d166ca48253b5a9

On Fri, Nov 6, 2015 at 11:00 AM, Daniel Holth wrote:

...

It should already be sorted. Try python -c "import pprint, pip.pep425tags; pprint.pprint(pip.pep425tags.get_supported())"

Do none of the tags for the available numpy wheels appear in that list?

On Fri, Nov 6, 2015 at 1:48 PM Robert McGibbon wrote:

...

Hi,

I just tried to run `pip install numpy` on my OS X 10.10.3 box, and it proceeds to download and compile the tarball from PyPI from source (very slow). I see, however, that pre-compiled OS X wheel files are available on PyPI for OS X 10.6 and later.

Checking the code, it looks like pip is picking up the platform tag through `distutils.util.get_platform()`, which returns 'macosx-10.5-x86_64' on this machine. At root, I think this comes from the MACOSX_DEPLOYMENT_TARGET=10.5 entry in the Makefile at `python3.5/config-3.5m/Makefile`. I know that this value is used by distutils compiling python extension modules -- presumably so that they can be distributed to any target machine with OS X >=10.5 -- so that's good. But is this the right thing for pip to be using when checking whether a binary wheel is compatible? I see it mentioned https://www.python.org/dev/peps/pep-0425/#id13 in PEP 425, so perhaps this was already hashed out on the list.

Best, Robert _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Sounds good. I'll take a look. -Robert On Fri, Nov 6, 2015 at 11:23 AM, Daniel Holth wrote:

If you would like to fix the problem, figure out how to get the real OSX version into pip.pep425tags.

On Fri, Nov 6, 2015 at 2:20 PM Robert McGibbon wrote:

...

For OS X, the pip get_platform function eventually calls into here: https://github.com/python/cpython/blob/master/Lib/_osx_support.py#L429-L439, and I think the comment kind of explains the bug.

-Robert

On Fri, Nov 6, 2015 at 11:10 AM, Daniel Holth wrote:

...

I see what you mean. Sounds like a bug to me.

On Fri, Nov 6, 2015 at 2:07 PM Robert McGibbon wrote:

...

I don't think it's the sorting, per se. All of the get_supported() tags are 10.5 or earlier. Here's the output: https://gist.github.com/rmcgibbo/1d0f5d166ca48253b5a9

On Fri, Nov 6, 2015 at 11:00 AM, Daniel Holth wrote:

...

It should already be sorted. Try python -c "import pprint, pip.pep425tags; pprint.pprint(pip.pep425tags.get_supported())"

Do none of the tags for the available numpy wheels appear in that list?

On Fri, Nov 6, 2015 at 1:48 PM Robert McGibbon wrote:

...

Hi,

I just tried to run `pip install numpy` on my OS X 10.10.3 box, and it proceeds to download and compile the tarball from PyPI from source (very slow). I see, however, that pre-compiled OS X wheel files are available on PyPI for OS X 10.6 and later.

Checking the code, it looks like pip is picking up the platform tag through `distutils.util.get_platform()`, which returns 'macosx-10.5-x86_64' on this machine. At root, I think this comes from the MACOSX_DEPLOYMENT_TARGET=10.5 entry in the Makefile at `python3.5/config-3.5m/Makefile`. I know that this value is used by distutils compiling python extension modules -- presumably so that they can be distributed to any target machine with OS X >=10.5 -- so that's good. But is this the right thing for pip to be using when checking whether a binary wheel is compatible? I see it mentioned https://www.python.org/dev/peps/pep-0425/#id13 in PEP 425, so perhaps this was already hashed out on the list.

Best, Robert _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

I'm using the Python from the Miniconda installer with py35 released last week. What does the python.org installer build for 10.6+ return for `distutils.util.get_platform()`? -Robert On Fri, Nov 6, 2015 at 2:50 PM, Ned Deily wrote:

...

I just tried to run `pip install numpy` on my OS X 10.10.3 box, and it proceeds to download and compile the tarball from PyPI from source (very slow). I see, however, that pre-compiled OS X wheel files are available on PyPI for OS X 10.6 and later.

Checking the code, it looks like pip is picking up the platform tag

...

`distutils.util.get_platform()`, which returns 'macosx-10.5-x86_64' on

...

machine. At root, I think this comes from the MACOSX_DEPLOYMENT_TARGET=10.5 entry in the Makefile at `python3.5/config-3.5m/Makefile`. I know that

...

value is used by distutils compiling python extension modules --

In article , Robert McGibbon wrote: through this this presumably

...

so that they can be distributed to any target machine with OS X >=10.5 -- so that's good. But is this the right thing for pip to be using when checking whether a binary wheel is compatible? I see it mentioned https://www.python.org/dev/peps/pep-0425/#id13 in PEP 425, so perhaps this was already hashed out on the list.

Are you using an OS X Python installed from a python.org installer? If so, be aware that there are two different OS X installers on Python.org for each current release. One is intended for 10.5 systems, although it will work on later OS X systems. The other is for 10.6 and later systems. Unless you have a need to run on 10.5 or build something that works on 10.5, download and use the 10.6+ installers instead. Then the existing whls for products like Numpy should work just fine.

-- Ned Deily, nad@acm.org

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

On Nov 6, 2015, at 3:57 PM, Robert McGibbon wrote: I'm using the Python from the Miniconda installer with py35 released last week. Then you should not expect it to be able to find compatible binary wheels on PyPi. Pretty much the entire point of conda is to support Numpy and friends. It's actually really good that it DIDN'T go and install a binary wheel. You want: conda install numpy Trust me on that :-) There are some cases where pip installing a source package into a conda Python is fine -- but mostly only pure-Python packages. -CHB What does the python.org installer build for 10.6+ return for `distutils.util.get_platform()`? -Robert On Fri, Nov 6, 2015 at 2:50 PM, Ned Deily wrote:

...

I just tried to run `pip install numpy` on my OS X 10.10.3 box, and it proceeds to download and compile the tarball from PyPI from source (very slow). I see, however, that pre-compiled OS X wheel files are available on PyPI for OS X 10.6 and later.

Checking the code, it looks like pip is picking up the platform tag

...

`distutils.util.get_platform()`, which returns 'macosx-10.5-x86_64' on

...

machine. At root, I think this comes from the MACOSX_DEPLOYMENT_TARGET=10.5 entry in the Makefile at `python3.5/config-3.5m/Makefile`. I know that

...

value is used by distutils compiling python extension modules --

In article , Robert McGibbon wrote: through this this presumably

...

so that they can be distributed to any target machine with OS X >=10.5 -- so that's good. But is this the right thing for pip to be using when checking whether a binary wheel is compatible? I see it mentioned https://www.python.org/dev/peps/pep-0425/#id13 in PEP 425, so perhaps this was already hashed out on the list.

Are you using an OS X Python installed from a python.org installer? If so, be aware that there are two different OS X installers on Python.org http://python.org for each current release. One is intended for 10.5 systems, although it will work on later OS X systems. The other is for 10.6 and later systems. Unless you have a need to run on 10.5 or build something that works on 10.5, download and use the 10.6+ installers instead. Then the existing whls for products like Numpy should work just fine.

-- Ned Deily, nad@acm.org

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

On Sat, Nov 7, 2015 at 1:04 AM, Chris Barker - NOAA Federal < chris.barker@noaa.gov> wrote:

On Nov 6, 2015, at 3:57 PM, Robert McGibbon wrote:

I'm using the Python from the Miniconda installer with py35 released last week.

Then you should not expect it to be able to find compatible binary wheels on PyPi.

Pretty much the entire point of conda is to support Numpy and friends. It's actually really good that it DIDN'T go and install a binary wheel.

You want:

conda install numpy

Trust me on that :-)

There are some cases where pip installing a source package into a conda Python is fine -- but mostly only pure-Python packages.

Actually, the situation with pip on OS X is quite good. This should work with at least python.org Python, MacPython and Homebrew (using wheels): pip install numpy scipy matplotlib pandas scikit-image scikit-learn Ralf