[Python-Dev] Python XML Validator

[Stefan Behnel]

Mike Meyer wrote:
> On Tue, 11 Mar 2008 14:55:04 +0100 Stefan Behnel <stefan_ml at behnel.de> wrote:
>> (weird places these threads come up at, but now that it's here...)
>> Mike Meyer wrote:
>>> On Tue, 04 Mar 2008 15:44:32 -0800 Ned Deily <nad at acm.org> wrote:
>>>> In article <20080302230708.260fa4a9 at bhuda.mired.org>,
>>>>  Mike Meyer <mwm at mired.org> wrote:
>>>>> On Thu, 28 Feb 2008 23:42:49 +0000 (UTC) Medhat Gayed 
>>>>> <medhat.gayed at gmail.com> wrote:
>>>>>> lxml is good but not written in python and difficult to install and didn't 
>>>>>> work on MacOS X.
> 
> Please note that this original complaint is *not* mine. However...
> 
>> Due to a design problem in MacOS-X, not a problem in lxml.
> 
> I didn't find it noticeably harder to install lxml on MacOS-X than
> most other systems.

It seems to be for a number of people, though, who turn up on the mailing list
complaining about just that.


>> But it's not that hard to install either, as previous posts presented.
> 
> Depends on how you define "hard". If I have to create a custom
> environment with updated version of system libraries just to use lxml,
> I'd call that "hard". That was pretty much the only route available
> the first time I wanted lxml on OS-X. And ubuntu. And RHEL.

It got a lot better by now. The only problem is how to tell your operating
system where to look for libraries that you installed yourself (which I still
refuse to consider a problem of lxml).

BTW, we had MacOS builds a while ago, so I wouldn't mind having someone
volunteer to contribute builds on a regular basis (static builds preferred).


> The second time for OS-X, I used an older version of lxml (1.3.6), and
> just did "setup.py install". Worked like a charm. That's not hard.

Interesting. 1.3.6 should also require libxml2 2.6.20 (although maybe less
strictly than 2.0).


>>> However, the authors tend to require recent
>>> versions of libxml2 and libxslt, which means recent versions of lxml
>>> won't build and/or work with the libraries bundled with many Unix and
>>> Unix-like systems
>> I wouldn't consider a dependency on an almost three year old library version
>> "recent", libxml2 2.6.20 was released in July 2005.
> 
> Well, if you're on a development box that you update regularly, you're
> right: three years old is pretty old. If you're talking about a
> production box that you don't touch unless you absolutely have to,
> you're wrong: three years old is still pretty recent. For example, the
> most recent release of RHEL is 4.6, which ships with libxml2 2.6.16.

Ok, that's pretty old, although that was the last version we supported before
requiring 2.6.20 (last summer, somewhere in the 1.3 series). Anyway, it's
definitely less of a problem to upgrade system libraries on Linux (IIRC "rpm
-bs" helps you on older RH*L versions) than under MacOS.


>>> Which means you wind up having to
>>> build those yourself if you want a recent version of lxml, even if
>>> you're using a system that includes lxml in it's package system.
>> If you want a clean system, e.g. for production use, buildout has proven to be
>> a good idea. And we also provide pretty good instructions on our web page on
>> how to install lxml on MacOS-X and what to take care of.
> 
> Yes, but the proposal was to include it in the Python standard
> library. Software that doesn't work on popular target platforms
> without updating a standard system library isn't really suitable for
> that.

Hmm, coming somewhat back on-topic: how does Python currently handle its
dependencies under MacOS-X? SQLite, for example? Does it use system libraries
only, or are there libraries it ships with? (The MacOS distro is much bigger,
but that might be due to the universal build - although that suggests that
MacOS-X users do not care about disk space or download size anyway)

It looks like it already ships with expat on all platforms, so why not add
libxml2/libxslt to the distribution, at least on platforms where it's
necessary? (happily ignoring the fact here that lxml isn't currently even
close to being integrated)

Admittedly, that would add some 1.3MB (uncompressed) to the distro...

Regarding updated version requirements: those are always discussed on the
mailing list. The only reason we had for continued support of 2.6.16 was
MacOS-X 10.4, until we found that most users installed newer libraries anyway,
because the old ones were just too old and crash-prone.

Stefan