Calling all Mac OSX users!

In article

Ok, there has been a lot of useful discussion (for both MacOSX and Windows),
but in the end, I want to know this: Is it possible for matplotlib to
provide a single, recommended, fully-supported-by-us method for installing
our package (possibly for each platform?). Could it be pip? Or some other

I think we'll always need to be able to install from source and also
offer a binary on MacOS X.

* Build from source.

If your version of MacOS X is recent enough then building from source
could easily be made to work (with a few minor changes to
Most other projects have managed this. I may be able to find some time
to work on this.

On the good side it would work with nearly any python build and it means
any user can install matplotlib in the obvious fashion. For these
reasons I think this is very much worth doing. However, it has some
- It requires that users install XCode
- I don't think the resulting build will work with older versions of
MacOS X, because Apple's libraries aren't backward compatible. This
means the user will run into unexpected difficulty if they build and
distribute a bundled application. This is a serious problem and means
that users must have a binary installer option:

* Binary installer (.mpkg or egg)

This is how things are done now. The binary installer can include
statically linked backward compatible libraries and thus be compatible
with many versions of MacOS X. Thus users can safely include matplotlib
in bundled applications.

There are many choices, including Apple's build-in python,,
Enthought, ActiveState, MacPorts... Most projects, including matplotlib,
provide binary installers for python because Apple's python
is useless for distributed apps and is hard to upgrade, and most other
projects provide their own installers for matplotlib.

So I would hate to see matplotlib give up on binary installers, but we
could and should improve our ability to build matplotlib from source on
MacOS X.

Another issue is how to distribute the binary installers. I like .mpkg
installers because they are pretty good about installing with compatible
versions of Python. We've tried binary eggs in the past and they were
not good about finding the right version of Python. That may have

-- Russell


Benjamin Root <ben.root@...553...> wrote: