[Python-Dev] Python XML Validator

[Stefan Behnel]

(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.

Due to a design problem in MacOS-X, not a problem in lxml.

But it's not that hard to install either, as previous posts presented.


>>> lxml is built on top of libxml2/libxslt, which are bundled with most
>>> Unix-like OS's (including Mac OS X), or available in their package
>>> systems. Trying to install it from the repository is a PITA, because
>>> it uses both the easyinstall and Pyrex (later Cython) packages

Using a release version of lxml does not require you to install any of the
two. Just download the tar.gz, unpack it, and do the usual setup.py dance.
That's how package installation in Python works.

It does, however, require you to have libxml2 and libxslt installed with their
dependencies, but that has nothing to do with Python.


>>> aren't bundled with anything. On the other hand, if it's in the
>>> package system (I no longer have macports installed anywhere, but
>>> believe it was there at one time), that solves all those problems. I
>>> believe they've excised the easyinstall source dependencies, though.

There is no source dependency on easy_install. I assume that all they did is:
build lxml against the libxml2/libxslt libraries that come with macports.
Which is a sensible thing to do IMHO.


> I think lxml is the best Python XML library that meets his
> requirements, and it would make my life a lot easier if it were part
> of the standard library.

I don't object to that. I'm just not a major driver here as it would require a
bit of work that I can't currently spare.


> 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.


> - including OSX.

That's different, because the system libraries here are a) horribly outdated
for every new version of MacOS-X (i.e. usually more than two years old and
very buggy), and b) difficult to replace by design.


> 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.

Stefan