more wheels and eggs

[minrk]

If you are interested, I built the following eggs and wheels

• Python.org Python 2.7 and 3.3 (target is 10.6)
• Anaconda 2.7 and 3.3 (target is 10.5)

Because of the arch checking policy in pip, none of the wheels you posted will actually install on either of these Pythons (the two most common, in my experience).

[ludwigschwardt]

Excellent!

I'm hoping these binaries will reduce the number of build issues on the Mac, so it is great to be able to include the most common ones. I'm now on Homebrew Python (previously on System Python), so haven't tried these out yet.

Do you have a bunch of virtualenvs for these? How can we automate the build process (more) in future?

Will the Anaconda 2.7 wheel instead on all versions of Mac OS X >= 10.5? I have access to a 10.6, 10.7 and 10.9 machine, but no 10.8 and was wondering how important it is to compile on these different platforms.

[ludwigschwardt]

Thanks, uploaded these.

[minrk]

Do you have a bunch of virtualenvs for these?

a mixture of virtualenvs and conda envs.

How can we automate the build process (more) in future?

It's pretty easy if you have the envs already to write a shell script that does:

for env in my envs; do
    source env/bin/activate
    python setup.py bdist_wheel bdist_egg
done

This is what I tend to do (for example).

But that said, you might be able to automate the whole thing, including env creation, with something like tox. That might be overkill, though.

Will the Anaconda 2.7 wheel instead on all versions of Mac OS X >= 10.5?

Sadly, no. pip has decided to require equality of OS X version, rather than matching what setuptools has always done for eggs, which is ≥. Since it is ambiguous what should be done, I opened a PR against pip to restore the ≥ behavior, but I am not optimistic about it.

[ludwigschwardt]

Hi Min,

This is what I tend to do (for example).

Great script! I'll look into this approach.

Sadly, no.

So if a 10.5 conda wheel won't install on 10.9, what's the point? :-)

[minrk]

So if a 10.5 conda wheel won't install on 10.9, what's the point? :-)

Sorry, I was unclear. This wheel will run on all Anaconda installs, but ~no Python other than Anaconda. The OS X version in the wheel denotes the deployment target of Python, not the system on which it is running. Anaconda is always 10.5, no matter what system it is running on, just as Python.org is always 10.6.

[ludwigschwardt]

OK, thanks for clearing that up...

Two questions:

• Just to make sure, does that mean that I can build those Anaconda 10.5 and Python.org 10.6 wheels on Mavericks or any other OS >= 10.6, using the normal setup.py process?
• OK, so "pip install gnureadline" gets the source tarball instead of the wheel. Can the user then download the wheel manually from PyPI and still somehow install it with pip? Can you install a wheel without using pip? This is what prompted my previous question.

[minrk]

Just to make sure, does that mean that I can build those Anaconda 10.5 and Python.org 10.6 wheels on Mavericks or any other OS >= 10.6, using the normal setup.py process?

Yes.

OK, so "pip install gnureadline" gets the source tarball instead of the wheel. Can the user then download the wheel manually from PyPI and still somehow install it with pip? Can you install a wheel without using pip? This is what prompted my previous question.

On older pip, you will want to use pip install --use-wheel gnureadline to prefer the wheel. On current pip, this is the default behavior unless you set use_wheel = False in ~/.pip/pip.conf. If you pip install /path/or/url/to/gnureadline.whl, it will install the wheel.

The full output of installing gnureadline for me:

[prompt] $ pip install gnureadline
Downloading/unpacking gnureadline
  Downloading gnureadline-6.2.5-cp33-cp33m-macosx_10_6_intel.whl (245kB): 245kB downloaded
Installing collected packages: gnureadline
Successfully installed gnureadline
Cleaning up...
[prompt] $ 

[ludwigschwardt]

OK, cool! It all makes sense now.

So basically to cover most common scenarios I need to produce (egg, wheel) x (10.5, 10.6, 10.7, 10.8, 10.9) x (2.7, 3.3) x (64-bit only, 32+64-bit) = 40 files :-) Although not all OS versions need both CPU flavours.

This is where tools like twine really become useful.