What should an OS-X build of MPL look like?

Community matplotlib-users
1

Hi all,

I'm hoping to contribute to the effort to of providing pre-built packages for the new Universal Build of Python 2.4.3 for OS-X. They'll go up on pythonmac.org eventually. I'd like to get some consensus for what the MPL package should look like.

In the past, I've done it this way:

libpng and libfreetype statically linked

Support for tk and wx.

No support for GTK.

How does this look for folks?

Does anyone use PyGTK with the Framework build of Python (rather than darwinports or fink)? If so, if someone can either build a package for it or tell me how, I could support that as well.

Charlie: I know you've been building packages -- how are you doing it? for what Python? Maybe I don't have anything to do.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

2

I absolutely agree with statically linking in libpng and
freetype. This just makes sense, since it leaves no dependencies.
Anyone who is using GTK most likely does not care for a native mac
solution and would be using fink or darwin port's python. As of late
I usually build an egg with tk, wx, and the 3 pyarrays with the static
libs as mentioned above. This seems to be very portable. I would be
happy to test anything you create or even help in the process, but I
am guessing you'll have no problems.

- Charlie

···

On 3/28/06, Christopher Barker <Chris.Barker@...259...> wrote:

Hi all,

I'm hoping to contribute to the effort to of providing pre-built
packages for the new Universal Build of Python 2.4.3 for OS-X. They'll
go up on pythonmac.org eventually. I'd like to get some consensus for
what the MPL package should look like.

In the past, I've done it this way:

libpng and libfreetype statically linked

Support for tk and wx.

No support for GTK.

How does this look for folks?

Does anyone use PyGTK with the Framework build of Python (rather than
darwinports or fink)? If so, if someone can either build a package for
it or tell me how, I could support that as well.

Charlie: I know you've been building packages -- how are you doing it?
for what Python? Maybe I don't have anything to do.

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

3

Charlie Moad wrote:

     I absolutely agree with statically linking in libpng and
freetype. This just makes sense, since it leaves no dependencies. Anyone who is using GTK most likely does not care for a native mac
solution and would be using fink or darwin port's python. As of late
I usually build an egg with tk, wx, and the 3 pyarrays with the static
libs as mentioned above.

Which Python build are you using?

At the moment, there is not a Universal wxPython, and Py2App/bdist_mpkg is not yet working with the Universal build, so I may wait for those two before I do a Universal build of MPL.

As packages built for the 2.4.1 Framework build work fine with the Universal build (on PPC machines) then I can probably just use what you've built for the moment.

By the way, what's the status of the cocoa back-end? And the Cairo Back-end on OS-X (and other platforms, while I'm asking)

> This seems to be very portable. I would be

happy to test anything you create

I don't suppose you have an Intel Mac do you? That's what would really need testing. Or OS-X 10.3.9 -- I'm only running 10.4 on PPC.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

4

Charlie Moad wrote:
> I absolutely agree with statically linking in libpng and
> freetype. This just makes sense, since it leaves no dependencies.
> Anyone who is using GTK most likely does not care for a native mac
> solution and would be using fink or darwin port's python. As of late
> I usually build an egg with tk, wx, and the 3 pyarrays with the static
> libs as mentioned above.

Which Python build are you using?

Typically I use OSX's python, but I don't want to start that debate.
I also build everything from source. New users should probably be
pointed to the prebuilt 2.4 framework on pythonmac. I haven't been
keeping up with the intel status though.

At the moment, there is not a Universal wxPython, and Py2App/bdist_mpkg
is not yet working with the Universal build, so I may wait for those two
  before I do a Universal build of MPL.

As packages built for the 2.4.1 Framework build work fine with the
Universal build (on PPC machines) then I can probably just use what
you've built for the moment.

Are eggs accepted by pythonmac yet or they still using mpkg's exclusively?

By the way, what's the status of the cocoa back-end? And the Cairo
Back-end on OS-X (and other platforms, while I'm asking)

Cocoa-agg works and has been there for the last few releases. There
are some quirks with multiple figures/windows. A toolbar has not been
implemented yet though. I still see the cocoa-agg as being sample
code on embedding matplotlib into a cocoa app. It doesn't have much
benefit in my eyes over tkagg.

When I first started the cocoa backend, I attempted it using quartz.
The graphics were actually really easy to get working. As I think
will be the case with Cairo, the text was the big hangup. Apple's
python interface to quartz doesn't have much of the text support
included. I think it is much better to focus on the Agg backend and
use it in gui toolkits. Otherwise, we will play this never-ending
game of trying to make the rendered results match between the
different rendering engines. Also by using the Agg backend, the
Cocoa-agg gets all the features of Agg for free. These don't have to
be re-implemented.

> This seems to be very portable. I would be
> happy to test anything you create

I don't suppose you have an Intel Mac do you? That's what would really
need testing. Or OS-X 10.3.9 -- I'm only running 10.4 on PPC.

10.4 PPC : (

···

On 3/29/06, Christopher Barker <Chris.Barker@...259...> wrote:

5

Charlie Moad wrote:

Typically I use OSX's python, but I don't want to start that debate.

No need for debate, I just wanted to know, so I wouldn't be duplicating effort. I'm trying to support the new Universal Build (and the 2.4.1 Framework Build before that), so I wanted to know if I'm duplicating effort.

New users should probably be
pointed to the prebuilt 2.4 framework on pythonmac.

Yup!

I haven't been keeping up with the intel status though.

There is a new universal build of 2.4.3 We're all hoping it will become the "standard" build for OS-X >= 10.3.9, for both PPC and Intel. However, it can't really be that until we can get all the critical packages built for it. wxPython is a big hang up now, and I consider matplotlib critical too.

Are eggs accepted by pythonmac yet or they still using mpkg's exclusively?

We'd like to put eggs on there too. ideally, we'd make a little launcher app that would fire up and run easy_install to install them when double clicked. That's been talked about, but not yet done. In the meantime, something is better than nothing!

Cocoa-agg works and has been there for the last few releases.

Will it build by default on OS-X?

Apple's
python interface to quartz doesn't have much of the text support
included.

Darn. And it's proprietary isn't it?

I think it is much better to focus on the Agg backend and
use it in gui toolkits.

That is a good plan, unless we go to using All-Cairo Doing both seems way too redundant. I'm investigating Cairo vs. Agg for another project.

These are my quick thoughts:

Cairo Pluses:
   In theory: native, hardware accelerated back-ends for various platforms

   PDF and PS support: That's very nice, then we'd really have only one back-end! (what about Tex?)

   It's being used for GTK2 and part of Mozilla, so it should see a lot of activity and testing.

Cairo Minuses:
   It doesn't look like there's much activity on Windows, but that's gotten better with the Mozilla folks getting involved. I don't know about OS-X

Agg pluses:
   It works now!

   It has fabulous anti-aliasing (I haven't compared to Cairo yet)

   It's smaller and simpler.

Anyone else have some thoughts?

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

6

> Cocoa-agg works and has been there for the last few releases.

Will it build by default on OS-X?

It is pure python and a bundled nib, so it is included in all distributions.