Hi,
As some of you may know, using lxml on OSX is a big pain because of an incompatible system version of libxml2. The solution is to ship binary eggs, which we already do for Windows.
Now, as a first test, Stefan has uploaded this egg:
lxml-2.2.1-py2.4-macosx-10.5-i386.egg
See http://pypi.python.org/pypi/lxml/2.2.1
Now, I'm on OSX 10.5, and I've requested this exact version.
In a virtualenv, this works. It downloads the given binary egg.
In a buildout, it's preferring to download and build the egg itself, and it calls it lxml-2.2.1-py2.4-macosx-10.3-i386.egg. That's weird, because this machine has never had OSX 10.3 on it. :(
My Python 2.4.6 is installed via darwinports.
Now, I can probably work around this, but we're trying to ensure that people have a sane lxml egg that will install cleanly on a number of platforms. It's therefore pretty important that the average user doesn't get this.
So, I'd like to try and figure out what's going on. How does buildout decide which egg to look for? Why is easy_install in a virtualenv behaving differently to my buildout?
Martin
Martin Aspeli wrote:
Hi,
As some of you may know, using lxml on OSX is a big pain because of an incompatible system version of libxml2. The solution is to ship binary eggs, which we already do for Windows.
Now, as a first test, Stefan has uploaded this egg:
lxml-2.2.1-py2.4-macosx-10.5-i386.egg
See http://pypi.python.org/pypi/lxml/2.2.1
Now, I'm on OSX 10.5, and I've requested this exact version.
In a virtualenv, this works. It downloads the given binary egg.
In a buildout, it's preferring to download and build the egg itself, and it calls it lxml-2.2.1-py2.4-macosx-10.3-i386.egg. That's weird, because this machine has never had OSX 10.3 on it. :(
My Python 2.4.6 is installed via darwinports.
Now, I can probably work around this, but we're trying to ensure that people have a sane lxml egg that will install cleanly on a number of platforms. It's therefore pretty important that the average user doesn't get this.
So, I'd like to try and figure out what's going on. How does buildout decide which egg to look for? Why is easy_install in a virtualenv behaving differently to my buildout?
Okay - I just wiped my parts/, bin/ and .installed.cfg and ran bootstrap again. This time, it's building an egg called 10.5, but it's still building its own from the source rather than downloading the binary egg. :(
Martin
I plan to add an option to force source or binary eggs to be used. Something like:
egg-type = any|binary|source
where any is the default. I haven't gotten to this yet. :)
It would probably be nice to specify this at the part level.
Jim
On Jun 27, 2009, at 9:13 AM, Martin Aspeli wrote:
Martin Aspeli wrote:
Hi, As some of you may know, using lxml on OSX is a big pain because of an incompatible system version of libxml2. The solution is to ship binary eggs, which we already do for Windows. Now, as a first test, Stefan has uploaded this egg: lxml-2.2.1-py2.4-macosx-10.5-i386.egg See http://pypi.python.org/pypi/lxml/2.2.1 Now, I'm on OSX 10.5, and I've requested this exact version. In a virtualenv, this works. It downloads the given binary egg. In a buildout, it's preferring to download and build the egg itself, and it calls it lxml-2.2.1-py2.4-macosx-10.3-i386.egg. That's weird, because this machine has never had OSX 10.3 on it. :( My Python 2.4.6 is installed via darwinports. Now, I can probably work around this, but we're trying to ensure that people have a sane lxml egg that will install cleanly on a number of platforms. It's therefore pretty important that the average user doesn't get this. So, I'd like to try and figure out what's going on. How does buildout decide which egg to look for? Why is easy_install in a virtualenv behaving differently to my buildout?
Okay - I just wiped my parts/, bin/ and .installed.cfg and ran bootstrap again. This time, it's building an egg called 10.5, but it's still building its own from the source rather than downloading the binary egg. :(
Martin
-- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Jim Fulton Zope Corporation
Jim Fulton wrote:
I plan to add an option to force source or binary eggs to be used. Something like:
egg-type = any|binary|source
where any is the default. I haven't gotten to this yet. :)
It would probably be nice to specify this at the part level.
Agree.
In the meantime, I think I found the problem: I have a shared download cache, and the .tgz was cached there. When I removed it, buildout started preferring the egg on PyPI.
I still have no idea why it was building an osx-10.3 egg before I re-did bootstrap, though. Note that I'd upgraded my MacPorts supplied Python 2.4 from 2.4.5 to 2.4.6 in between setting up the buildout initially, and doing the wipe-and-re-bootstrap.
Martin
-
Jim Fulton -
Martin Aspeli