[lxml-dev] lxml Mac installation idea

[Stefan Behnel]

Chris Withers wrote:
> Stefan Behnel wrote:
>>> Out of interest, what's the canonical way to build lxml when you're
>>> developing it? What's the canonical way to run the unit tests?
>>
>> Not sure I do it the "canonical" way, but I usually run "make test",
>
> What does "make test" do?

You asked for a way to run the unit tests, that's what "make test" does.
You can find the respective commands in the Makefile, or read the web
page.

https://codespeak.net/lxml/build.html#running-the-tests-and-reporting-errors


>> sometimes
>> passing PYTHON=..., sometimes setting XML2_CONFIG=... and
>> XSLT_CONFIG=...
>
> This is to test with different versions of python, libxml2 and libxslt,
> right?

Yes. If you want to make sure it takes the right library at runtime, call
setup.py with --auto-rpath on Linux.


>> We don't have a contributor for MacOS binaries.
>
> Well, I have Macs, if there's a recipe to follow and no-one else is
> prepared to do it, I'd be more than happy to do so...

As I said, this would be very much appreciated. The first thing I would
ask you to do is check out the current trunk from SVN

https://codespeak.net/lxml/build.html#subversion

make sure you have an Internet connection to download libxml2/libxslt, and
then run

    python setup.py build_ext -i --static-deps

to download and build the libs and then statically build lxml with them.
This will copy the modules into their package at the end, so you should be
able to run

    python test.py -vv

afterwards to see if it works as expected. Please report any errors you
get on the way.


>> I happily accept binary builds for any system where users have problems
>> in
>> getting lxml built automatically. If buildout helps here, fine with me.
>
> Nope, I haven't heard anything that suggests buildout would help for
> projects that aren't already using buildout...

You could use buildout to build a static egg, though.

Anyway, if we get the built-in "--static-deps" way to work reliably,
that's much better than a buildout.


> It *is* a shame though that while, for Windows users, they just need to
> do "easy_install lxml", linux users have to make sure a bunch of
> packages are installed first :-/

I partly agree, although it's not so many packages at all (2 to be exact,
or 3 if your Python comes with a -dev package also), and installing them
once will usually instruct your system to keep them up-to-date for you.

Windows is a mostly uniform target platform (e.g. x86 only) which lacks
support for very basic things like package management and software
compilation, but also (mostly) lacks a standard directory layout - you can
basically install your software wherever you like. So, finding things that
are already installed is actually hard on Windows, as is keeping the
system updated (at least for things that do not come from MS). That makes
a static, complete installer the best choice. It's even better to install
dependencies 100 times in parallel, than to risk conflicts, or even rely
on them being up-to-date.

GNU/Linux is a very diverse but well standardised target platform (LSB)
with very good support for package management, online software
distribution, and software building. So it's much easier to target that
platform with a source release than with a binary build.

Stefan