At 06:04 PM 7/26/2010 +0100, Chris Withers wrote:
Hi All,
In addition to the UCS2/4 problems already described by MAL and
which I've bumped into myself, I now have a problem with binary
linux eggs where the GCC version doesn't match that of the system
the egg is being installed on.
Current egg metadata doesn't take either of these into account or
even provide a way for the nature of the binary egg to be recorded.
How're people coping with this?
What are the future plans in this area?
Egg binaries aren't a great idea on Linux; they were mainly intended
for Windows and Mac, where the architectures are uniform and working
compilers aren't just an apt-get or yum away.
(Ironically, this is a side effect of eggs being invented *before*
easy_install; if I'd thought of easy_install *first*, I might not've
bothered with eggs (as a distribution format) at all. Certainly,
sdists don't add a lot of installation overhead except on
compiler-less platforms.)
Incidentally, if you look way, way back in the distutils-sig
archives, you can see where I first raised the question of platform
strings and addressing some of these issues, but at the time nobody
was interested. Since then, the topic gets raised periodically, but
there has never been anyone with enough of both interest and
knowledge to put together a concrete proposal for overhauling
platform strings on *nix platforms.
OS/X and Windows, OTOH, have had proposals implemented either in
distutils or setuptools over the last few years. (Distutils needs
code to *distinguish* platforms (by changing the strings), but
setuptools only needs special code to be able to tell when the
running platform supports running something built with a different
platform string. So, additions of UCS build info to distutils would
probably not affect setuptools; addition of gcc info might.)
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
