[matplotlib-devel] I have a Mac!

Community matplotlib-users
1

(Replying to the list, rather than just George)

···

On Aug 29, 2013 8:18 AM, “Matt Terry” <matt.terry@…287…> wrote:

I have 15/17 variants working. each pulling binaries/source from some combination of macports/brew/python.org/pip on python 2.6, 2.7, 3.2, and 3.3.

https://travis-ci.org/mrterry/mpl_on_travis_mac/builds/10733852

I need to add python27 and python33 variants that install XQuartz. Other than that, are there any builds that should be added? For reference,

python.org 27 / pip numpy
python.org 27 / numpy dmg
python.org 33 / pip numpy (no official python3 numpy installer)
(all built with static versions of libpng/freetype)

system python + brew dependencies
system python + brew dependencies*

brew python27
brew python27*

brew python33
brew python33*

macports py26
macports py27
macports py32
macports py33
macports py26*
macports py27*
macports py32*
macports py33*

  • = virtual envs. python & c dependencies installed from package manager; macports, numpy from macports. --with-site-packages

I’m having a strange installation issue involving dateutil on python 3.3 (only). It is a bytes vs unicode (fight!) that manifests on installation. I can’t reproduce the issue on my machine, but it may have something to do with dateutil v2.1. Anyone seen something like this? installing dateutil via macports cleans up the issue (it installs 2.0, i think).

-matt

On Thu, Aug 29, 2013 at 4:47 AM, George Nurser <gnurser@…287…> wrote:

It might be useful to see how macports does it – their builds have always worked for me.

George Nurser.

On 23 August 2013 18:53, Chris Barker - NOAA Federal <chris.barker@…259…> wrote:

On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <matt.terry@…287…> wrote:

I’m banging away at installing MPL on top of python.org’s python.

This is why binary installers are good idea!

the libfreetype/freetype issue.

yeah, that’s kind of ugly…and where is doesn’t “just work” for me…

  1. install libpng[1] and freetype[2] from source

libpng and freetype are different, though install from source may be
the way to go:

libpng is there, but is not properly installed, I’m not sure it’s got
the header for the same version as the lib, and libpng-config is
either not there or not for the right version or somethign ugly. It
look, form messages at build time, that someone has hacked some code
into the MPL build that figures all that out, but for other stuff I’m
doing, I just punt and build libpng – that’s pretty straighforward,
at least. But teh solution in the MPL code now seems to work.

  1. install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell’s
    directions[4]) so MPL finds XQuartz’s libpng/freetype

I think that OS-X now ships with X11, which has freetype (though
installed weirdly once again…) we certainly should NOT expect people
to install anything big to build MPL, and binaries should not depend
on anything not shipped by Apple by default.

According to Russell, you do need to install something, so I think that’s out.

  1. create the MPL binary installer and use that

That’s what most people should do – but one of us needs to build it.

Option 1 seems simple-est, but installing freetype requires more than
./configure && make && sudo make install.

darn. But hopefully we can figure it out.

Option 4: This would require some input from whoever (Gohlke?, Owen?) makes
the binary installers.

I think Russell has been doing it for MPL lately.

My thoughts:

We want to support two user-bases:

  1. folks that don’t mind a little command line work, and probably need
    other scientific libs, etc anyway, an want an MPL that runs on their
    machine:

    • these folks should use homebrew or macports to build the
      dependencies (or even hand-compile them). Ideally we have setup.py
      that will find those libs, and test to see that the builds work once
      in a while.

  2. folks that “just want to use it” and/or want a binary they can
    re-distribute via py2app, etc.

  • for these folks, we need to provide binaries. These binaries should:
  1. Match the python.org python builds. (probably only the Intel ones now…)
  2. statically link the non-sytem libs

This has been done for a while, off and on, most recently by Russell, AFAIK.

But this is not a problem unique to MPL. All sorts of python packages
need this, and only some of the package maintainers do it (well).
Also, a bunch of packages require the same dependencies (i.e. PIL and
MPL both need png and freetype)

So, rather than re-inventing the wheel over and over again, It would
be great to have a central repository where we can develop build
scripts, etc that share an infrustructure for building these binaries.

I’ve started one:

https://github.com/MacPython/mac-builds

there is not much there, only a couple things I’m working on at the
moment (netCDF4, which is of interest to scipy folks, and py_gd, which
is my own simple drawing lib, that no one else uses (yet?)

If anyone wants to join the project let me know – if I know you from
your work with this community, I’ll gladly add you.

I’m using the gattai build system:
(https://sourceforge.net/projects/gattai/). I decided to do that, as I
was sick of re-writing essentially the same build scripts, and I kept
adding features to mine that would have resulted in re-implementing
gattai anyway. I’ve been hacking at gattai, and its author is quite
open to moving it forward.

That being said, there is no reason that we need to use the same build
system – we could easily have custom build scripts for a project, and
still have it share the dependencies.

I was planning on getting it all further along before announcing the
project and looking for help, but since is came up…

-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

Chris.Barker@…2155…

Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk

Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Learn the latest–Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk

Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

2

Very impressive! This is really great.

That does sure look like a dateutil bug. Maybe we try reporting it over there?

As for transferring the repository... I've added you as a developer in the matplotlib organization, so you can work over there. And it looks like you are the only one who can do the transfer, see here: Transferring a repository - GitHub Docs

I'll ping Travis again about how multi-OS testing might work, because it would be *absolutely killer* to get this going on matplotlib PRs.

Mike

···

On 08/29/2013 01:01 PM, Matt Terry wrote:

(Replying to the list, rather than just George)
On Aug 29, 2013 8:18 AM, "Matt Terry" <matt.terry@...287... > <mailto:matt.terry@…287…>> wrote:
>
> I have 15/17 variants working. each pulling binaries/source from some combination of macports/brew/python.org/pip <http://python.org/pip&gt; on python 2.6, 2.7, 3.2, and 3.3.
>
> Travis CI - Test and Deploy with Confidence
>
> I need to add python27 and python33 variants that install XQuartz. Other than that, are there any builds that should be added? For reference,
>
> python.org <http://python.org> 27 / pip numpy
> python.org <http://python.org> 27 / numpy dmg
> python.org <http://python.org> 33 / pip numpy (no official python3 numpy installer)
> (all built with static versions of libpng/freetype)
>
> system python + brew dependencies
> system python + brew dependencies*
>
> brew python27
> brew python27*
>
> brew python33
> brew python33*
>
> macports py26
> macports py27
> macports py32
> macports py33
> macports py26*
> macports py27*
> macports py32*
> macports py33*
>
> * = virtual envs. python & c dependencies installed from package manager; macports, numpy from macports. --with-site-packages
>
> I'm having a strange installation issue involving dateutil on python 3.3 (only). It is a bytes vs unicode (fight!) that manifests on installation. I can't reproduce the issue on my machine, but it may have something to do with dateutil v2.1. Anyone seen something like this? installing dateutil via macports cleans up the issue (it installs 2.0, i think).
>
> -matt
>
> On Thu, Aug 29, 2013 at 4:47 AM, George Nurser <gnurser@...287... > <mailto:gnurser@…287…>> wrote:
>>
>> It might be useful to see how macports does it -- their builds have always worked for me.
>>
>> George Nurser.
>>
>> On 23 August 2013 18:53, Chris Barker - NOAA Federal > <chris.barker@...259... <mailto:chris.barker@…259…>> wrote:
>>>
>>> On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <matt.terry@...287... > <mailto:matt.terry@…287…>> wrote:
>>> > I'm banging away at installing MPL on top of python.org <http://python.org>'s python.
>>>
>>> This is why binary installers are good idea!
>>>
>>> > the libfreetype/freetype issue.
>>>
>>> yeah, that's kind of ugly....and where is doesn't "just work" for me...
>>>
>>> > 1) install libpng[1] and freetype[2] from source
>>>
>>> libpng and freetype are different, though install from source may be
>>> the way to go:
>>>
>>> libpng is there, but is not properly installed, I'm not sure it's got
>>> the header for the same version as the lib, and libpng-config is
>>> either not there or not for the right version or somethign ugly. It
>>> look, form messages at build time, that someone has hacked some code
>>> into the MPL build that figures all that out, but for other stuff I'm
>>> doing, I just punt and build libpng -- that's pretty straighforward,
>>> at least. But teh solution in the MPL code now seems to work.
>>>
>>> > 2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's
>>> > directions[4]) so MPL finds XQuartz's libpng/freetype
>>>
>>> I _think_ that OS-X now ships with X11, which has freetype (though
>>> installed weirdly once again...) we certainly should NOT expect people
>>> to install anything big to build MPL, and binaries should not depend
>>> on anything not shipped by Apple by default.
>>>
>>> According to Russell, you do need to install something, so I think that's out.
>>>
>>> > 4) create the MPL binary installer and use that
>>>
>>> That's what most people should do -- but one of us needs to build it.
>>>
>>> > Option 1 seems simple-est, but installing freetype requires more than
>>> > ./configure && make && sudo make install.
>>>
>>> darn. But hopefully we can figure it out.
>>>
>>> > Option 4: This would require some input from whoever (Gohlke?, Owen?) makes
>>> > the binary installers.
>>>
>>> I think Russell has been doing it for MPL lately.
>>>
>>> My thoughts:
>>>
>>> We want to support two user-bases:
>>>
>>> 1) folks that don't mind a little command line work, and probably need
>>> other scientific libs, etc anyway, an want an MPL that runs on their
>>> machine:
>>> - these folks should use homebrew or macports to build the
>>> dependencies (or even hand-compile them). Ideally we have setup.py
>>> that will find those libs, and test to see that the builds work once
>>> in a while.
>>>
>>> 2) folks that "just want to use it" and/or want a binary they can
>>> re-distribute via py2app, etc.
>>> - for these folks, we need to provide binaries. These binaries should:
>>> 1) Match the python.org <http://python.org> python builds. (probably only the Intel ones now...)
>>> 2) statically link the non-sytem libs
>>>
>>> This has been done for a while, off and on, most recently by Russell, AFAIK.
>>>
>>> But this is not a problem unique to MPL. All sorts of python packages
>>> need this, and only some of the package maintainers do it (well).
>>> Also, a bunch of packages require the same dependencies (i.e. PIL and
>>> MPL both need png and freetype)
>>>
>>> So, rather than re-inventing the wheel over and over again, It would
>>> be great to have a central repository where we can develop build
>>> scripts, etc that share an infrustructure for building these binaries.
>>>
>>> I've started one:
>>>
>>> GitHub - MacPython/mac-builds: Gattai recipes for building various pyton packages for the Mac
>>>
>>> there is not much there, only a couple things I'm working on at the
>>> moment (netCDF4, which is of interest to scipy folks, and py_gd, which
>>> is my own simple drawing lib, that no one else uses (yet?)
>>>
>>> If anyone wants to join the project let me know -- if I know you from
>>> your work with this community, I'll gladly add you.
>>>
>>> I'm using the gattai build system:
>>> (gattai download | SourceForge.net). I decided to do that, as I
>>> was sick of re-writing essentially the same build scripts, and I kept
>>> adding features to mine that would have resulted in re-implementing
>>> gattai anyway. I've been hacking at gattai, and its author is quite
>>> open to moving it forward.
>>>
>>> That being said, there is no reason that we need to use the same build
>>> system -- we could easily have custom build scripts for a project, and
>>> still have it share the dependencies.
>>>
>>> I was planning on getting it all further along before announcing the
>>> project and looking for help, but since is came up...
>>>
>>> -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
>>>
>>> Chris.Barker@...259... <mailto:Chris.Barker@…259…>
>>>
>>> ------------------------------------------------------------------------------
>>> Introducing Performance Central, a new site from SourceForge and
>>> AppDynamics. Performance Central is your source for news, insights,
>>> analysis and resources for efficient Application Performance Management.
>>> Visit us today!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Matplotlib-users@lists.sourceforge.net <mailto:Matplotlib-users@lists.sourceforge.net>
>>> matplotlib-users List Signup and Options
>>
>> ------------------------------------------------------------------------------
>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>> Discover the easy way to master current and previous Microsoft technologies
>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>> tutorial videos with LearnDevNow. Subscribe today and save!
>> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Matplotlib-users@lists.sourceforge.net <mailto:Matplotlib-users@lists.sourceforge.net>
>> matplotlib-users List Signup and Options
>>
>

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

3

BTW: I've got uploading of test results to S3 working on the main matplotlib repository. It would be cool to do that here, too, but I believe the encrypted keys are specific to the github repo. We can coordinate off-line once the repo is transferred about how to do this.

Mike

···

On 08/29/2013 01:01 PM, Matt Terry wrote:

(Replying to the list, rather than just George)
On Aug 29, 2013 8:18 AM, "Matt Terry" <matt.terry@...287... > <mailto:matt.terry@…287…>> wrote:
>
> I have 15/17 variants working. each pulling binaries/source from some combination of macports/brew/python.org/pip <http://python.org/pip&gt; on python 2.6, 2.7, 3.2, and 3.3.
>
> Travis CI - Test and Deploy with Confidence
>
> I need to add python27 and python33 variants that install XQuartz. Other than that, are there any builds that should be added? For reference,
>
> python.org <http://python.org> 27 / pip numpy
> python.org <http://python.org> 27 / numpy dmg
> python.org <http://python.org> 33 / pip numpy (no official python3 numpy installer)
> (all built with static versions of libpng/freetype)
>
> system python + brew dependencies
> system python + brew dependencies*
>
> brew python27
> brew python27*
>
> brew python33
> brew python33*
>
> macports py26
> macports py27
> macports py32
> macports py33
> macports py26*
> macports py27*
> macports py32*
> macports py33*
>
> * = virtual envs. python & c dependencies installed from package manager; macports, numpy from macports. --with-site-packages
>
> I'm having a strange installation issue involving dateutil on python 3.3 (only). It is a bytes vs unicode (fight!) that manifests on installation. I can't reproduce the issue on my machine, but it may have something to do with dateutil v2.1. Anyone seen something like this? installing dateutil via macports cleans up the issue (it installs 2.0, i think).
>
> -matt
>
> On Thu, Aug 29, 2013 at 4:47 AM, George Nurser <gnurser@...287... > <mailto:gnurser@…287…>> wrote:
>>
>> It might be useful to see how macports does it -- their builds have always worked for me.
>>
>> George Nurser.
>>
>> On 23 August 2013 18:53, Chris Barker - NOAA Federal > <chris.barker@...259... <mailto:chris.barker@…259…>> wrote:
>>>
>>> On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <matt.terry@...287... > <mailto:matt.terry@…287…>> wrote:
>>> > I'm banging away at installing MPL on top of python.org <http://python.org>'s python.
>>>
>>> This is why binary installers are good idea!
>>>
>>> > the libfreetype/freetype issue.
>>>
>>> yeah, that's kind of ugly....and where is doesn't "just work" for me...
>>>
>>> > 1) install libpng[1] and freetype[2] from source
>>>
>>> libpng and freetype are different, though install from source may be
>>> the way to go:
>>>
>>> libpng is there, but is not properly installed, I'm not sure it's got
>>> the header for the same version as the lib, and libpng-config is
>>> either not there or not for the right version or somethign ugly. It
>>> look, form messages at build time, that someone has hacked some code
>>> into the MPL build that figures all that out, but for other stuff I'm
>>> doing, I just punt and build libpng -- that's pretty straighforward,
>>> at least. But teh solution in the MPL code now seems to work.
>>>
>>> > 2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's
>>> > directions[4]) so MPL finds XQuartz's libpng/freetype
>>>
>>> I _think_ that OS-X now ships with X11, which has freetype (though
>>> installed weirdly once again...) we certainly should NOT expect people
>>> to install anything big to build MPL, and binaries should not depend
>>> on anything not shipped by Apple by default.
>>>
>>> According to Russell, you do need to install something, so I think that's out.
>>>
>>> > 4) create the MPL binary installer and use that
>>>
>>> That's what most people should do -- but one of us needs to build it.
>>>
>>> > Option 1 seems simple-est, but installing freetype requires more than
>>> > ./configure && make && sudo make install.
>>>
>>> darn. But hopefully we can figure it out.
>>>
>>> > Option 4: This would require some input from whoever (Gohlke?, Owen?) makes
>>> > the binary installers.
>>>
>>> I think Russell has been doing it for MPL lately.
>>>
>>> My thoughts:
>>>
>>> We want to support two user-bases:
>>>
>>> 1) folks that don't mind a little command line work, and probably need
>>> other scientific libs, etc anyway, an want an MPL that runs on their
>>> machine:
>>> - these folks should use homebrew or macports to build the
>>> dependencies (or even hand-compile them). Ideally we have setup.py
>>> that will find those libs, and test to see that the builds work once
>>> in a while.
>>>
>>> 2) folks that "just want to use it" and/or want a binary they can
>>> re-distribute via py2app, etc.
>>> - for these folks, we need to provide binaries. These binaries should:
>>> 1) Match the python.org <http://python.org> python builds. (probably only the Intel ones now...)
>>> 2) statically link the non-sytem libs
>>>
>>> This has been done for a while, off and on, most recently by Russell, AFAIK.
>>>
>>> But this is not a problem unique to MPL. All sorts of python packages
>>> need this, and only some of the package maintainers do it (well).
>>> Also, a bunch of packages require the same dependencies (i.e. PIL and
>>> MPL both need png and freetype)
>>>
>>> So, rather than re-inventing the wheel over and over again, It would
>>> be great to have a central repository where we can develop build
>>> scripts, etc that share an infrustructure for building these binaries.
>>>
>>> I've started one:
>>>
>>> GitHub - MacPython/mac-builds: Gattai recipes for building various pyton packages for the Mac
>>>
>>> there is not much there, only a couple things I'm working on at the
>>> moment (netCDF4, which is of interest to scipy folks, and py_gd, which
>>> is my own simple drawing lib, that no one else uses (yet?)
>>>
>>> If anyone wants to join the project let me know -- if I know you from
>>> your work with this community, I'll gladly add you.
>>>
>>> I'm using the gattai build system:
>>> (gattai download | SourceForge.net). I decided to do that, as I
>>> was sick of re-writing essentially the same build scripts, and I kept
>>> adding features to mine that would have resulted in re-implementing
>>> gattai anyway. I've been hacking at gattai, and its author is quite
>>> open to moving it forward.
>>>
>>> That being said, there is no reason that we need to use the same build
>>> system -- we could easily have custom build scripts for a project, and
>>> still have it share the dependencies.
>>>
>>> I was planning on getting it all further along before announcing the
>>> project and looking for help, but since is came up...
>>>
>>> -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
>>>
>>> Chris.Barker@...259... <mailto:Chris.Barker@…259…>
>>>
>>> ------------------------------------------------------------------------------
>>> Introducing Performance Central, a new site from SourceForge and
>>> AppDynamics. Performance Central is your source for news, insights,
>>> analysis and resources for efficient Application Performance Management.
>>> Visit us today!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Matplotlib-users@lists.sourceforge.net <mailto:Matplotlib-users@lists.sourceforge.net>
>>> matplotlib-users List Signup and Options
>>
>> ------------------------------------------------------------------------------
>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>> Discover the easy way to master current and previous Microsoft technologies
>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>> tutorial videos with LearnDevNow. Subscribe today and save!
>> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Matplotlib-users@lists.sourceforge.net <mailto:Matplotlib-users@lists.sourceforge.net>
>> matplotlib-users List Signup and Options
>>
>

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

4

I tried transferring the repo, but apparently I need admin privileges to do so. Github recommends creating a team with no repos, and then adding me there.

Right now my testing repo is pulling matplotlib/master. It would be really easy to make it pull from a different url (specified in an environment variable, perhaps). Travis would just need to poke mpl_on_travis_mac for each pull request.

-matt

···

On Fri, Aug 30, 2013 at 8:46 AM, Michael Droettboom <mdroe@…86…> wrote:

  BTW: I've got uploading of test results

to S3 working on the main matplotlib repository. It would be cool
to do that here, too, but I believe the encrypted keys are
specific to the github repo. We can coordinate off-line once the
repo is transferred about how to do this.

  Mike



  On 08/29/2013 01:01 PM, Matt Terry wrote:

(Replying to the list, rather than just George)
On Aug 29, 2013 8:18 AM, “Matt Terry” <matt.terry@…287… >
wrote:
>
> I have 15/17 variants working. each pulling
binaries/source from some combination of macports/brew/python.org/pip
on python 2.6, 2.7, 3.2, and 3.3.
>
> https://travis-ci.org/mrterry/mpl_on_travis_mac/builds/10733852
>
> I need to add python27 and python33 variants that install
XQuartz. Other than that, are there any builds that should be
added? For reference,
>
> python.org
27 / pip numpy
> python.org
27 / numpy dmg
> python.org
33 / pip numpy (no official python3 numpy installer)
> (all built with static versions of libpng/freetype)
>
> system python + brew dependencies
> system python + brew dependencies*
>
> brew python27
> brew python27*
>
> brew python33
> brew python33*
>
> macports py26
> macports py27
> macports py32
> macports py33
> macports py26*
> macports py27*
> macports py32*
> macports py33*
>
> * = virtual envs. python & c dependencies installed
from package manager; macports, numpy from macports.
–with-site-packages
>
>
> I’m having a strange installation issue involving dateutil
on python 3.3 (only). It is a bytes vs unicode (fight!) that
manifests on installation. I can’t reproduce the issue on my
machine, but it may have something to do with dateutil v2.1.
Anyone seen something like this? installing dateutil via
macports cleans up the issue (it installs 2.0, i think).
>
> -matt
>
>
>
>
> On Thu, Aug 29, 2013 at 4:47 AM, George Nurser <gnurser@…287… >
wrote:
>>
>> It might be useful to see how macports does it – their
builds have always worked for me.
>>
>> George Nurser.
>>
>>
>> On 23 August 2013 18:53, Chris Barker - NOAA Federal
<chris.barker@…259… >
wrote:
>>>
>>> On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <matt.terry@…287… >
wrote:
>>> > I’m banging away at installing MPL on top of python.org 's
python.
>>>
>>> This is why binary installers are good idea!
>>>
>>> > the libfreetype/freetype issue.
>>>
>>> yeah, that’s kind of ugly…and where is doesn’t
“just work” for me…
>>>
>>> > 1) install libpng[1] and freetype[2] from
source
>>>
>>> libpng and freetype are different, though install
from source may be
>>> the way to go:
>>>
>>> libpng is there, but is not properly installed, I’m
not sure it’s got
>>> the header for the same version as the lib, and
libpng-config is
>>> either not there or not for the right version or
somethign ugly. It
>>> look, form messages at build time, that someone has
hacked some code
>>> into the MPL build that figures all that out, but
for other stuff I’m
>>> doing, I just punt and build libpng – that’s
pretty straighforward,
>>> at least. But teh solution in the MPL code now
seems to work.
>>>
>>> > 2) install XQuartz[3] and twiddle /opt/X11,
/usr/X11 (per Russell’s
>>> > directions[4]) so MPL finds XQuartz’s
libpng/freetype
>>>
>>> I think that OS-X now ships with X11, which has
freetype (though
>>> installed weirdly once again…) we certainly
should NOT expect people
>>> to install anything big to build MPL, and binaries
should not depend
>>> on anything not shipped by Apple by default.
>>>
>>> According to Russell, you do need to install
something, so I think that’s out.
>>>
>>> > 4) create the MPL binary installer and use
that
>>>
>>> That’s what most people should do – but one of us
needs to build it.
>>>
>>> > Option 1 seems simple-est, but installing
freetype requires more than
>>> > ./configure && make && sudo
make install.
>>>
>>> darn. But hopefully we can figure it out.
>>>
>>> > Option 4: This would require some input from
whoever (Gohlke?, Owen?) makes
>>> > the binary installers.
>>>
>>> I think Russell has been doing it for MPL lately.
>>>
>>> My thoughts:
>>>
>>> We want to support two user-bases:
>>>
>>> 1) folks that don’t mind a little command line
work, and probably need
>>> other scientific libs, etc anyway, an want an MPL
that runs on their
>>> machine:
>>> - these folks should use homebrew or macports to
build the
>>> dependencies (or even hand-compile them). Ideally
we have setup.py
>>> that will find those libs, and test to see that the
builds work once
>>> in a while.
>>>
>>> 2) folks that “just want to use it” and/or want a
binary they can
>>> re-distribute via py2app, etc.
>>> - for these folks, we need to provide binaries.
These binaries should:
>>> 1) Match the python.org python builds.
(probably only the Intel ones now…)
>>> 2) statically link the non-sytem libs
>>>
>>> This has been done for a while, off and on, most
recently by Russell, AFAIK.
>>>
>>> But this is not a problem unique to MPL. All sorts
of python packages
>>> need this, and only some of the package maintainers
do it (well).
>>> Also, a bunch of packages require the same
dependencies (i.e. PIL and
>>> MPL both need png and freetype)
>>>
>>> So, rather than re-inventing the wheel over and
over again, It would
>>> be great to have a central repository where we can
develop build
>>> scripts, etc that share an infrustructure for
building these binaries.
>>>
>>> I’ve started one:
>>>
>>> https://github.com/MacPython/mac-builds
>>>
>>> there is not much there, only a couple things I’m
working on at the
>>> moment (netCDF4, which is of interest to scipy
folks, and py_gd, which
>>> is my own simple drawing lib, that no one else uses
(yet?)
>>>
>>> If anyone wants to join the project let me know –
if I know you from
>>> your work with this community, I’ll gladly add you.
>>>
>>> I’m using the gattai build system:
>>> (https://sourceforge.net/projects/gattai/ ).
I decided to do that, as I
>>> was sick of re-writing essentially the same build
scripts, and I kept
>>> adding features to mine that would have resulted in
re-implementing
>>> gattai anyway. I’ve been hacking at gattai, and its
author is quite
>>> open to moving it forward.
>>>
>>> That being said, there is no reason that we need to
use the same build
>>> system – we could easily have custom build scripts
for a project, and
>>> still have it share the dependencies.
>>>
>>> I was planning on getting it all further along
before announcing the
>>> project and looking for help, but since is came
up…
>>>
>>> -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
>>>
>>> Chris.Barker@…259…
>>>
>>>

    >>> Introducing Performance Central, a new site from

SourceForge and
>>> AppDynamics. Performance Central is your source for
news, insights,
>>> analysis and resources for efficient Application
Performance Management.
>>> Visit us today!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Matplotlib-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>>
>>

    >> Learn the latest--Visual Studio 2012, SharePoint 2013,

SQL 2012, more!
>> Discover the easy way to master current and previous
Microsoft technologies
>> and advance your career. Get an incredible 1,500+ hours
of step-by-step
>> tutorial videos with LearnDevNow. Subscribe today and
save!
>> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Matplotlib-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
[http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk](http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk)

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
[https://lists.sourceforge.net/lists/listinfo/matplotlib-users](https://lists.sourceforge.net/lists/listinfo/matplotlib-users)

Learn the latest–Visual Studio 2012, SharePoint 2013, SQL 2012, more!

Discover the easy way to master current and previous Microsoft technologies

and advance your career. Get an incredible 1,500+ hours of step-by-step

tutorial videos with LearnDevNow. Subscribe today and save!

http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk

Matplotlib-users mailing list

Matplotlib-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-users