[Pythonmac-SIG] Dependencies for Python packages on OS-X

[Christopher Barker]

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 
cool.

>> 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 
> about).

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?

-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 at noaa.gov