easy_install of a fat binary .egg which was built on Mac OS 10.4 fails on Mac OS 10.5 #212
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#212
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
So, dreid and Peter both get bizarre behavior from easy_install when they try to install a .egg which I built on Mac OS 10.4.
Another example is simplejson, which wasn't built by me. Peter's computer fails on "easy_install simplejson", after it installs the source tarball (why not the binary egg?) and then fails to compile it. (Because Peter doesn't have Xcode installed yet.)
It appears that easy_install on Mac OS 10.5 thinks that an egg named "macosx-10.3-fat.egg" is not usable, but Mac OS 10.4 thinks that such an egg is usable.
Note that "setup.py bdist" on Mac OS 10.4 produces eggs named "macosx-10.3-fat.egg".
PJE says that the OS X platform versioning code was contributed by someone other than he to pkg_resources, and that it works by reading /usr/bin/sw_vers.
The next step is to post to the Mac SIG mailing list about this issue.
easy_install of a fat binary .egg which was built on Mac OS 10.4 fails on Mac OS 10.5... or somethingto easy_install of a fat binary .egg which was built on Mac OS 10.4 fails on Mac OS 10.5I've reported this issue to the Python Mac SIG and they are apparently working on fixing it in future releases of Python:
http://www.nabble.com/does-pkg_resources-think-that--22macosx-10.3-22-is-incompatible-with-10.5--to13865060.html#a13865060
Here is the ticket for this issue on the setuptools tracker:
http://bugs.python.org/setuptools/issue19
Maybe we could revisit this issue after switching to the new fork of setuptools named "Distribute":
http://tarekziade.wordpress.com/2009/07/22/preparing-to-release-distribute-0-6/
I guess what we really need to do is boil this down to a simple test case -- build a .egg on Mac OS 10.4 and then try to install it on Mac OS 10.5.
There have been some updates to http://bugs.python.org/setuptools/issue19 . It sounds like the Python/distutils/setuptools/distribute folks aren't going to fix this issue anytime soon.
both of the versions of Mac OS X mentioned in this ticket are obsolete. closing.
How do we know this isn't still a problem between two more recent versions of Mac OS X? That should be tested before closing the ticket.
This will be somebody else's problem when we switch to a newer setuptools that supports wheel distributions.