[lxml-dev] lxml Mac installation idea

[Stefan Behnel]

Hi Ian,

Ian Bicking wrote:
> Stefan Behnel wrote:
> but I'd like it to work without buildout, and there's also several
> buildout recipes and configurations out there and not one clear
> canonical way to build lxml.

I wouldn't mind to ship lxml with a buildout recipe. I think the current
problem is that if we wait to find one that works well for as many people as
possible, we'll wait forever. So I'm fine with adding any script that's
somewhat tested and in use. Even a set of scripts that you can try is better
than none if people can't manage to build lxml themselves.


>>> 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.
> 
> Another option is yet another environmental variable to set the
> libxml2/libxslt versions, which are set to defaults.  If you chose a
> version that didn't exist in the tarball it'd download that version.

What about providing a script that checks for the most recent version first,
and then builds lxml with that? The "LATEST_IS_X.Y.Z" file in the libxml2 FTP
directory will help here. Then it's fine to override the latest version with
an env variable if people need to.


>>> 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.
> 
> No, I was just thinking about ways of structuring a full build (that
> includes the libxml2 library) and the current build.

Shipping with the latest libxml2/libxslt is not a big problem, setup.py could
be changed to support a "--all-sources" option for sdist. There could be a
separate tar.gz (or zip) file on PyPI that easy_install won't find at all. And
when the build detects that the libxml2 and libxslt sources lie next to the
src directory, it can switch to a static build automatically.

It's not an unsolvable problem, these things just need to get implemented.


> * Macs come with bad versions of libxml2 and libxslt (depending on the
> version of the OS, you get either very bad, or not as bad, but bad
> enough that you'll eventually get a segfault but not immediately, which
> is actually much worse)
>
> * People keep getting the wrong runtime linking, and DYLD_LIBRARY_PATH
> seems to be necessary.

That makes a case for a static build, IMHO.


> * There's several kinds of Python that people use on a Mac: at least the
> system python, macports python, and fink python.  I think there might be
> another.  They are all somewhat different.

I'm not sure this makes a difference, distutils should handle this. The only
problem is that this keeps us from preparing binaries for MacOS.


> * It's not that obvious how to build libxml2, unless you are using
> macports (which has a port for it).

Not sure what you mean here. Isn't cmmi enough?


> * Once you do build it, you have to be sure to get the right
> xml2-config, which doesn't happen by default.

Another reason for defaulting to a static build here.


> I do now have ssh access to a Mac.  Unfortunately it's behind our VPN,
> so I'm not sure if I can get you access to it too, but I'll ask about that.

I'm still waiting for the usual "we can pay you the hardware, so that you can
do the testing yourself" offers. ;o)

Stefan