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
