Because several people are reporting problems with the OS X egg, I grabbed matplotlib-0.98.5-py2.5-macosx-10.3.egg from sourceforge and unzipped it to see what was in there. It seems to contain no of the extension code and no object files. What exactly is this thing? I am no egg expert, but I don't see how this thing *could* work ... I think the src egg approach for os x is hopeless because too many people are having problems with architecture on png and zlib dependencies, and we don't have a lot of control over this because they are getting these dependencies from a variety of providers. I think we need a binary installer, eg using bdist_mpkg, with the freetype, png and zlib dependencies built in, as we have on windows. Any takers? JDH
On Sat, Dec 13, 2008 at 3:24 PM, John Hunter <jd...@gm...> wrote: > Because several people are reporting problems with the OS X egg, I > grabbed matplotlib-0.98.5-py2.5-macosx-10.3.egg from sourceforge and > unzipped it to see what was in there. It seems to contain no of the > extension code and no object files. What exactly is this thing? I am > no egg expert, but I don't see how this thing *could* work ... Hmm, it appears that I missed all the *.so files -- must work on my grep skills. Sorry for the noise JDH
This build should be the same as all the previous. I do them as I documented on the ipython pages. bdist_mpkg has been flat broke the times I have tried it. bdist_egg seems pretty helpless too due to setuptools lack of understanding of osx architectures. Most people get a successful install, but then setuptools tries to go out and grab the source anyways. I can't say that I know a good solution for osx. - Charlie On Sat, Dec 13, 2008 at 4:31 PM, John Hunter <jd...@gm...> wrote: > On Sat, Dec 13, 2008 at 3:24 PM, John Hunter <jd...@gm...> wrote: >> Because several people are reporting problems with the OS X egg, I >> grabbed matplotlib-0.98.5-py2.5-macosx-10.3.egg from sourceforge and >> unzipped it to see what was in there. It seems to contain no of the >> extension code and no object files. What exactly is this thing? I am >> no egg expert, but I don't see how this thing *could* work ... > > Hmm, it appears that I missed all the *.so files -- must work on my > grep skills. Sorry for the noise > > JDH > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
On Sat, Dec 13, 2008 at 3:24 PM, John Hunter <jd...@gm...> wrote: > I think the src egg approach for os x is hopeless because too many > people are having problems with architecture on png and zlib > dependencies, and we don't have a lot of control over this because > they are getting these dependencies from a variety of providers. I > think we need a binary installer, eg using bdist_mpkg, with the > freetype, png and zlib dependencies built in, as we have on windows. I worked on this yesterday on my flight back from the conference. I added a dir to the mpl src tree called release/osx that has a Makefile which has all the logic to fetch the bdist_mpkg (and patch it for 10.5), zlib, png, and freetype dependencies and build them using the protocol Charlie wrote at http://ipython.scipy.org/moin/MatplotlibOSXBuildNotes. It has a custom setup.cfg which is incorporated by the Makefile. In this way, we can get "1-click" or better yet "1-command" binary mpkg installers and binary eggs for OS X. I'm including the README below. We should be able to modify this approach to do the same for win32, and thus doing releases will become both easier and less error prone. One thing that was vexing me -- Charlie takes pains to avoid dynamically linking png and freetype in his instructions, and yet when I checked _png.so in the egg with :: otool -L _png.so it was pointing to /usr/X11R6/lib/libpng.dylib. I think I figured this out -- because I had PKG_CONFIG_PATH set in my local environment, the setupext check_for_libpng was picking it up on my local machine even though I had built a static libpng to link with for the binry installer. By unsetting this environment var, I get the static linkage we are shooting for. Is it possible that you have pkgconfig on your box Charlie, which is why the dynamic linking was creeping in? We need to fix setupext to respect a setup.cfg flag to not use pkgconfig in certain environments, eg when building installers. I've uploaded snapshots to http://matplotlib.sourceforge.net/snapshots/matplotlib-0.98.5-py2.5-macosx10.5.zip and http://matplotlib.sourceforge.net/snapshots/matplotlib-0.98.5_r0-py2.5-macosx-10.3-fat.egg So take a look. Here is the README from release/osx:: Building binary releases of OS X Included here is everything to build a binay package installer for OS X Dir Contents ------------- * :file:`bdist_mkpg` - the distutils.extension to build Installer.app mpkg installers. It is patched from the tarball with file:`data/bdist.patch` because 0.4.3 is broken on OS X 10.5. Instructions on how to patch and install are below * :file:`data` - some config files and patches needed for the build * :file:`*.tar.gz` - the bdist_mkpg, zlib, png, freetype and mpl tarballs * :file:`Makefile` - all the build commands How to build -------------- * You need to make sure to unset PKG_CONFIG_PATH to make sure the static linking below is respected. Otherwise the mpl build script will dynamically link using the libs from pkgconfig if you have this configured on your box:: unset PKG_CONFIG_PATH * OPTIONAL: edit :file:`Makefile` so that the *VERSION variables point to the latest zlib, png, freetype * First fetch all the dependencies and patch bdist_mpkg for OSX 10.5. You can do this automatically in one step with:: make fetch_deps * install the patched bdist_mpkg, that the fetch_deps step just created:: cd bdist_mpkg-0.4.3 sudo python setup.py install * build the dependencies:: make dependencies * copy over the latest mpl *.tar.gz tarball to this directory, update the MPLVERSION in the Makefile:: cp /path/to/mpl/matplotlib.0.98.5.tar.gz . * build the mkpg binary and egg make installers The mpkg and egg binaries will reside in :file:`matplotlib-VERSION/dist`
John Hunter wrote: > I think the src egg approach for os x is hopeless because too many > people are having problems with architecture on png and zlib > dependencies, and we don't have a lot of control over this because > they are getting these dependencies from a variety of providers. Maybe it's hopeless, but one solution is to try to standardize, in the MacPython community, on using William Kyngesburye's UnixImageIO and Freetype Frameworks for the dependencies: http://www.kyngchaos.com/wiki/doku.php?id=software:frameworks They are Universal, Binary, and packaged as nice frameworks and also with traditional unix-style layouts for building against. > I > think we need a binary installer, eg using bdist_mpkg, with the > freetype, png and zlib dependencies built in, as we have on windows. That's good route too, though it always feels a bit silly to have a different copy of libpng inside MPL, and PIL,and wxPython, and .... Why the heck Apple doesn't provide these really common libs is still beyond me! -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...
Charlie Moad wrote: > Most people > get a successful install, but then setuptools tries to go out and grab > the source anyways. I can't say that I know a good solution for osx. This may be moot due to what John H. has done, but I thought all you need to do to stop setuptools from going and grabbing the source is to re-name the egg -- couldn't we just put the same egg up on the website with different names for different OS versions? for instance, I renamed: matplotlib-0.98.3-py2.5-macosx-10.3.egg to: matplotlib-0.98.3-py2.5.egg and easy_install installed it without a hitch on 10.4 Indeed, that name may work for 10.5 too. -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...
On Tue, Dec 16, 2008 at 1:04 PM, Christopher Barker <Chr...@no...> wrote: > for instance, I renamed: > matplotlib-0.98.3-py2.5-macosx-10.3.egg > > to: > matplotlib-0.98.3-py2.5.egg > > and easy_install installed it without a hitch on 10.4 > > Indeed, that name may work for 10.5 too. I've posted new eggs and a binary mpkg installer for OS X and a new tarball. I've tried your egg renaming trick. Let me know how it goes. https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194&release_id=646644 You have two choices for OS X : * matplotlib-0.98.5.1-py2.5-macosx10.5.zip - a binary mpkg installer * matplotlib-0.98.5.1-py2.5-macosx.egg - an egg with the known problems fixed. Please give it another whirl and let me know. JDH > > -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... > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >