[Pythonmac-SIG] Dependencies for Python packages on OS-X
Chris.Barker at noaa.gov
Fri Apr 25 01:55:16 CEST 2008
William Kyngesburye wrote:
>> Is that right? Or should we just use our own for Apple's build too?
> Consistency is nice, especially on older systems that may have an old
> version where the changes include new features (as opposed to bug
> fixes). PNG updates are mostly bug fixes these days, but include
> important security updates that would be nice to have (Apple may update
> the system PNG but not X11 PNG?).
I'm confused -- are you suggesting that we use your Frameworks for all
this, even on newer apple systems that have them?
> Note: my frameworks are now for Tiger+ only. I dropped the Panther
> compatibility with the release of Leopard.
I can live with that.
> I'm working on a
> non-Xcode method to easily create frameworks from the unix sources
That would be a nice, A single script that does the whole build would be
>> William, what do you think of my idea of trying to get distributors to
>> standardize on your Frameworks?
> Thanks. That was generally the idea, but I'm not a very proactive
> person ;)
OK, so I'll keep pressing the point, but who knows? It really will only
work if it's widely adopted.
> Using static libs, even if everyone uses the same binary, is basically
> what occurs now. All it really does is relieve the developers of
> compiling dependencies (though that's part of what you're talking
Yes, that's exactly what I'm talking about. In order to build a package
for OS-X, and particularly to do it right (static libs, Universal), is
really a pain, so it's generally not done right. I like the dynamic libs
in a Framework approach better, but it's an extra dependency, and one
that setuptools can't bring in for you.
> But, static libs don't really belong in frameworks (and I don't
> like bloat).
No, but a standard place to get them and put them would be nice, if we
need static libs. I thought that building them along with your dynamic
ones would be minimal work. I suppose they could be put elsewhere, like
in /usr/local or something. The point is that there is now nowhere to
download these common static libs, and they are a pain to build.
> An option would be to bundle the frameworks in the Python framework. It
> would then be a courtesy of the Python packaging, and the Python
> packagers might not want to do that.
I suggested something like this a while back, but didn't get much
support. It's not really python, after all. But I think we could get
them put up on pythonmac.org/packages, right along with the python
install, and all the packages.
> If someone distributes a python application bundle (py2app or from
> Xcode), bundling the frameworks in that app's package would work, since
> framework bundling is standard stuff in applications.
Yup, it seems to be working for me with PIL.
> a Tiger/Leopard installer package can easily be made to
> do so.
yup. I figured that would work, and I don't think there would be any
problem if, for instance, the matplotlib and PIL installers both had
copies of the same UnixImageIO framework, would it?
> When I say existing installed frameworks, I mean compatible, though not
> necessarily more recent. With a common shared framework I don't think
> it would be nice to blow away an older version with a newer version if
> the older one is compatible. The installer can make the "update" optional.
can't the newer version and older version live side by side?
Anyway, I've almost got PIL tested, maybe you could make an installer
from it with the frameworks it needs?
Christopher Barker, Ph.D.
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 at noaa.gov
More information about the Pythonmac-SIG