Hi, Sorry for those of you on the numpy mailing list - this email will seem a bit familiar. I want to rename the matplotlib wheel OSX wheel files on pypi so they will also install into homebrew, macports and system python. I'm just doing this now for numpy and scipy, but I wanted to make sure y'all had no objections for matplotlib. The logic of the renaming is explained here: https://github.com/MacPython/wiki/wiki/Spinning-wheels Basically, by adding extra 'platform tags' to the wheel filename, we can signal to pip that the wheel is compatible with these other systems. The page above explains why the wheels I built are compatible with the other Pythons, and this test grid: https://travis-ci.org/matthew-brett/scipy-stack-osx-testing/builds/26482436 confirms that the renamed wheels install and test OK on homebrew, macports, system python. So, I propose to rename the current matplotlib python 2.7 wheel from: matplotlib-1.3.1-cp27-none-macosx_10_6_intel.whl to matplotlib-1.3.1-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl and so on for python 3.3, 3.4. I don't think this has a downside, but I'm happy for any feedback, Cheers, Matthew
On Mon, Jun 2, 2014 at 11:48 AM, Matthew Brett <mat...@gm...> wrote: > I want to rename the matplotlib wheel OSX wheel files on pypi so they > will also install into homebrew, macports and system python. > +1 > > matplotlib-1.3.1-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl > what is this going to do on OS-X 10.7 and 10.8 systems running homebrew or macports pythons? It seems this list could get pretty long! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
Hi, On Mon, Jun 2, 2014 at 5:14 PM, Chris Barker <chr...@no...> wrote: > On Mon, Jun 2, 2014 at 11:48 AM, Matthew Brett <mat...@gm...> > wrote: >> >> I want to rename the matplotlib wheel OSX wheel files on pypi so they >> will also install into homebrew, macports and system python. > > > +1 > >> >> >> matplotlib-1.3.1-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl > > > what is this going to do on OS-X 10.7 and 10.8 systems running homebrew or > macports pythons? It seems this list could get pretty long! Yes, it could, but this list: https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion suggests that 10.9 is the majority, and that 10.8 and 10.7 are only about 14 percent combined. I guess a better case could be made for 10.6 (still 16 percent), but I wonder how many 10.6 hold-outs are updating their homebrew / macports numpies regularly. Cheers, Matthew
On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett <mat...@gm...> wrote: > > what is this going to do on OS-X 10.7 and 10.8 systems running homebrew > or > > macports pythons? It seems this list could get pretty long! > Yes, it could, but this list: > > so we would have to add all those if we wanted to support them... > https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion > > very interesting stats! I wonder how representative those are? Makes we think we can drop 32 bit support, too. Maybe the newest 2.7 py.org binaries could be 64 bit only. It would simplify things a bit. > suggests that 10.9 is the majority, and that 10.8 and 10.7 are only > about 14 percent combined. I guess a better case could be made for > 10.6 (still 16 percent), but I wonder how many 10.6 hold-outs are > updating their homebrew / macports numpies regularly. > not many -- it can be a really a pain to do so -- macports and homebrew really expect you to have a recent compiler, which I think is difficult or impossible to install on 10.6... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
In article <CAL...@ma...>, Chris Barker <chr...@no...> wrote: > On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett > <mat...@gm...> > wrote: > > > > what is this going to do on OS-X 10.7 and 10.8 systems running homebrew > > or > > > macports pythons? It seems this list could get pretty long! > > > Yes, it could, but this list: > > > > so we would have to add all those if we wanted to support them... > > > > > https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion > > > > > very interesting stats! I wonder how representative those are? Makes we > think we can drop 32 bit support, too. Maybe the newest 2.7 py.org binaries > could be 64 bit only. It would simplify things a bit. I hope you will not drop 32-bit support yet.. I still use it to distribute some Tkinter apps. All recent versions of ActiveState Tcl/Tk 8.5 have a nasty crashing bug that I have not found a workaround for, and old enough versions that don't have the bug need to run in 32-bit mode on Mavericks. -- Russell
Hi, On Tue, Jun 3, 2014 at 1:00 PM, Russell E. Owen <ro...@uw...> wrote: > In article > <CAL...@ma...>, > Chris Barker <chr...@no...> wrote: > >> On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett >> <mat...@gm...> >> wrote: >> >> > > what is this going to do on OS-X 10.7 and 10.8 systems running homebrew >> > or >> > > macports pythons? It seems this list could get pretty long! >> > >> Yes, it could, but this list: >> > >> > so we would have to add all those if we wanted to support them... >> >> >> >> > https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion >> > >> > >> very interesting stats! I wonder how representative those are? Makes we >> think we can drop 32 bit support, too. Maybe the newest 2.7 py.org binaries >> could be 64 bit only. It would simplify things a bit. > > I hope you will not drop 32-bit support yet.. I still use it to > distribute some Tkinter apps. All recent versions of ActiveState Tcl/Tk > 8.5 have a nasty crashing bug that I have not found a workaround for, > and old enough versions that don't have the bug need to run in 32-bit > mode on Mavericks. Do you need 32 bit support for the wheels or just for the MacPython binaries? It's getting harder to build 32 / 64 bit universal binaries these days... Cheers, Matthew
Hi Russell, > > >Makes we > > think we can drop 32 bit support, too. Maybe the newest 2.7 py.org > binaries > > could be 64 bit only. It would simplify things a bit. > > I hope you will not drop 32-bit support yet.. I still use it to > distribute some Tkinter apps. All recent versions of ActiveState Tcl/Tk > 8.5 have a nasty crashing bug that I have not found a workaround for, > and old enough versions that don't have the bug need to run in 32-bit > mode on Mavericks. Darn. I guess it's not uncommon that even folks with a 64 bit machine may need a lib or something that is 32 bit only -- so maybe good to keep it. But it really is a pain -- and this example is supposed to be part of Python's stdlib! On Tue, Jun 3, 2014 at 1:44 PM, Matthew Brett <mat...@gm...> wrote: Do you need 32 bit support for the wheels or just for the MacPython > binaries? It's getting harder to build 32 / 64 bit universal > binaries these days... Exactly -- will an Intel Universal Python pick up a 64 bit-only wheel? That would be OK for most folks, I guess, though I'd really prefer it if things were more clear -- you have a 32/64 bit python, you install wheels and it works fine for you, so distribute via py2app, then it crashed when run in 32 bit mode... Oh well. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
In article <CAH6Pt5r_ZP8a-8U9TLBaRvH=PBb...@ma...>, Matthew Brett <mat...@gm...> wrote: > Hi, > > On Tue, Jun 3, 2014 at 1:00 PM, Russell E. Owen > <ro...@uw...> wrote: > > In article > > <CALGmxEL6geHVqGibWbUir3tovKs4KeGuW-qeTv5KMcsR40r-bQ-JsoAwUIsXosN+BqQ9rBEUg@ > > public.gmane.org>, > > Chris Barker <chr...@no...> wrote: > > > >> On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett > >> <mat...@gm...> > >> wrote: > >> > >> > > what is this going to do on OS-X 10.7 and 10.8 systems running > >> > > homebrew > >> > or > >> > > macports pythons? It seems this list could get pretty long! > >> > > >> Yes, it could, but this list: > >> > > >> > so we would have to add all those if we wanted to support them... > >> > >> > >> > >> > https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion > >> > > >> > > >> very interesting stats! I wonder how representative those are? Makes we > >> think we can drop 32 bit support, too. Maybe the newest 2.7 py.org > >> binaries > >> could be 64 bit only. It would simplify things a bit. > > > > I hope you will not drop 32-bit support yet.. I still use it to > > distribute some Tkinter apps. All recent versions of ActiveState Tcl/Tk > > 8.5 have a nasty crashing bug that I have not found a workaround for, > > and old enough versions that don't have the bug need to run in 32-bit > > mode on Mavericks. > > Do you need 32 bit support for the wheels or just for the MacPython > binaries? It's getting harder to build 32 / 64 bit universal > binaries these days... What I need is a python, numpy, and matplotlib that support 32-bit and (preferably) 64-bit for MacOS X 10.6 and later. I have been using python.org python and the standard binary installers until now. Until Mavericks I was using 64-bit mode. Unfortunately 32-bit is required for older versions of Tcl/Tk to run under Mavericks and as I noted, I can't use recent versions due to due to a bug (example appended) that I've not found a workaround for. I realize I'm in an unusual situation, and I"m not the one building the binaries and trying to deal with the ATLAS headaches. If worst comes to worst we can stay at the current version of numpy and matplotlib (at least for now). Long term we should probably switch away from Tcl/TK, though that would be a huge undertaking, or hire somebody to fix the Tcl/Tk bug. -- Russell # tcl menu crash; run in wish and push the Change Font button menu .parentMenu menu .parentMenu.apple -tearoff 0 # the following line is optional, but shows the menu is created .parentMenu add cascade -label Wish -menu .parentMenu.apple font create testFont option add "*Button.font" testFont button .btn -text "Change Font" -command { font configure testFont -size 20 } pack .btn . configure -menu .parentMenu
On Wed, Jun 4, 2014 at 2:12 PM, Russell E. Owen <ro...@uw...> wrote: > What I need is a python, numpy, and matplotlib that support 32-bit and > (preferably) 64-bit for MacOS X 10.6 and later. I have been using > python.org python and the standard binary installers until now. > well we (that is, Matthew) have scripts that build those, so no reason not to keep doing it. > Until Mavericks I was using 64-bit mode. Unfortunately 32-bit is > required for older versions of Tcl/Tk to run under Mavericks kind of ironic that the latest OS doesn't end up supporting 64 bit! > I realize I'm in an unusual situation, maybe -- but tkInter is part of the standard library, so we probably do want to support it! If nothing else, various folks that teach Python use the turtle module early on -- and one of the use cases for easy-to-fine-and-install binaries is newbies... > and I'm not the one building the > binaries and trying to deal with the ATLAS headaches. If worst comes to > worst we can stay at the current version of numpy and matplotlib (at > least for now). Long term we should probably switch away from Tcl/TK, > though that would be a huge undertaking, or hire somebody to fix the > Tcl/Tk bug. Is Tcl/Tk that unused that this isn't getting addressed? kind of Sad, though I was never a big fan -- at least once I discovered Python... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
Hi, On Thu, Jun 5, 2014 at 5:18 AM, Chris Barker <chr...@no...> wrote: > On Wed, Jun 4, 2014 at 2:12 PM, Russell E. Owen <ro...@uw...> wrote: >> >> What I need is a python, numpy, and matplotlib that support 32-bit and >> (preferably) 64-bit for MacOS X 10.6 and later. I have been using >> python.org python and the standard binary installers until now. > > > well we (that is, Matthew) have scripts that build those, so no reason not > to keep doing it. > >> >> Until Mavericks I was using 64-bit mode. Unfortunately 32-bit is >> required for older versions of Tcl/Tk to run under Mavericks > > > kind of ironic that the latest OS doesn't end up supporting 64 bit! > >> >> I realize I'm in an unusual situation, > > > maybe -- but tkInter is part of the standard library, so we probably do want > to support it! If nothing else, various folks that teach Python use the > turtle module early on -- and one of the use cases for > easy-to-fine-and-install binaries is newbies... Updating for those of you not on the numpy mailing list - I've uploaded 32 / 64 bit numpy / scipy wheels to pypi, so we should be good for 32-bit compatibility now. I hope that will continue for at least a couple of years, because I've automated the 32 / 64 bit build process [1] and added 32-bit tests to my scipy-stack test rig [2]. So, I think it is time to rename the matplotlib wheels as I proposed at the beginning of the thread. I propose to do that tomorrow unless anyone can think of a reason not to. Cheers, Matthew [1] https://github.com/matthew-brett/numpy-atlas-binaries [2] https://travis-ci.org/matthew-brett/scipy-stack-osx-testing
On Fri, Jun 20, 2014 at 12:01 PM, Matthew Brett <mat...@gm...> wrote: > Hi, > > On Thu, Jun 5, 2014 at 5:18 AM, Chris Barker <chr...@no...> wrote: >> On Wed, Jun 4, 2014 at 2:12 PM, Russell E. Owen <ro...@uw...> wrote: >>> >>> What I need is a python, numpy, and matplotlib that support 32-bit and >>> (preferably) 64-bit for MacOS X 10.6 and later. I have been using >>> python.org python and the standard binary installers until now. >> >> >> well we (that is, Matthew) have scripts that build those, so no reason not >> to keep doing it. >> >>> >>> Until Mavericks I was using 64-bit mode. Unfortunately 32-bit is >>> required for older versions of Tcl/Tk to run under Mavericks >> >> >> kind of ironic that the latest OS doesn't end up supporting 64 bit! >> >>> >>> I realize I'm in an unusual situation, >> >> >> maybe -- but tkInter is part of the standard library, so we probably do want >> to support it! If nothing else, various folks that teach Python use the >> turtle module early on -- and one of the use cases for >> easy-to-fine-and-install binaries is newbies... > > Updating for those of you not on the numpy mailing list - I've > uploaded 32 / 64 bit numpy / scipy wheels to pypi, so we should be > good for 32-bit compatibility now. I hope that will continue for at > least a couple of years, because I've automated the 32 / 64 bit build > process [1] and added 32-bit tests to my scipy-stack test rig [2]. > > So, I think it is time to rename the matplotlib wheels as I proposed > at the beginning of the thread. I propose to do that tomorrow unless > anyone can think of a reason not to. Done - please let me know if you have any problems. Matthew