Hi Ian, Ian Bicking wrote:
So... I hear that lxml installs better on a Mac if it's built along with libxml2/libxslt. That's not what everyone would do, so I was unclear how to enable something like that, and if setup.py would be the right place. A number of attempts to get stuff setup have been tried before external to lxml (like buildouts and now staticlxml).
I hadn't heard of static lxml yet, so I'll have to check what it's doing. Anyway, is it still that hard to install lxml on a Mac? Later 2.0 versions and 2.1 should behave much better here, given that they use "-flat_namespace" now.
While it's kind of lame, I wonder if enabling this static installation via an environmental variable would be reasonable? It would be easier to apply in a number of circumstances. I imagine it would mean something like, on installation, if a variable like LXML_INSTALL_STATIC (or INSTALL_LIBXML2 or something) was set, it'd download the libxml2 and libxslt libraries, run configure/make/make install with a prefix inside the lxml source directory itself, then build lxml using that library.
But isn't that what a buildout does best?
Another option would be simply a different tarball that contains the libxml2/libxslt source, and its setup.py would always build those. It could be versioned like 2.1static or something, which should keep it from being implicitly used by easy_install, etc. (since 2.1static is considered an earlier version than 2.1). This might be more reasonable?
The problem with this (and with the static Windows builds) is that libxml2/libxslt both have their release cycles, which are independent of lxml's releases. If you want to upgrade your libxml2 in a static build, you'll have to copy it to the right place anyway.
staticlxml is kind of weird, because installing staticlxml installs lxml, which can confuse tools.
Yep, I agree that that's not the way to go.
Maybe the two versions could be arranged with some svn:externals,
You mean lxml and libxml2? That would mean you either build libxml2 from a tag (implying the same problems as with a shipped, ready-to-get-outdated version), or from the trunk, which is definitely not suitable for most users.
or just as a build script of some sort (e.g., drop a marker file in the source to make it "static", and have setup.py look for that file and change the sdist/install commands appropriately).
That's just another way of triggering it, in which case I prefer the env var way.
One nuisance with any attempt to fix this is that I don't think either myself nor Stefan have ready access to a Mac to test this stuff...
Yes, that's part of the problem. Another problem is the way this problem pops up. From time to time, Mac users complain on the list that it doesn't work for them to build lxml. Some can provide helpful hints, debugging time or patches, others cannot. It's impossible for me to find out if things are really settled, or if there are still Mac users out there who just do not feel like investing any work to at least complain.
From what I witness, there haven't been any complains for a while, so I considered this problem settled since the late days of 2.0. If you bring it back up now (and if people feel urged to do things like staticlxml), it sounds to me like it's not.
Stefan