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

[EMAIL PROTECTED]
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Reply via email to