[lxml-dev] lxml Mac installation idea

[Stefan Behnel]

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