Comment 4 for bug 1176147

I have to seccond Kenneth, that having lxml distribution available in wheel format is real timesaver, which is about to change working style of thousands of Python app developers. Having lxml installed in fraction of second compared to minutes is real difference.

re: how would the binary look like:
at the time of lxml new version, build wheel using wheel tool. Yes, it woudl be statically linked.

re: static build preventing users from upgrading libxml2/libxslt independently from lxml.
Simply not true. Option to build it from sourde still remains there and anyone can make update, if he/she is really interested.

re: dynamically linked binaries don't work:
True. But nobody is asking for having it dynamically linekd, in fact, it could be source of possible problems.

re: source build is really the best option.
Keneth summarized the advantages very well. The overall savings would be really huge. Just count - measure standard compile time, measure optimized compile time (which almost noone uses, as nobody really knows, how to set this option into standard application buildout procedure), measure the time needed to install it from wheel. Take the differennce and multiply by number of developers, or even number of builds.

re: lxml builds quite quickly
I do not know, what is meant by "quite quickly". Is that less then wheel format?
I wanted to test the compilatin without optimizhation, but reading documentation for lxml is not now showing easy method, how to do it, pointing me to special page, dealing with this topic. But I am not C-programmer, I am developong Python applications and want to have it integrated into my test and build environment efficiently.
And even more important: why should I switch of optimization? Am I supposed to run CI test using differently compiled component then in production?

There are pros and cons of having wheel format for lxml. They shall be evaluated and compared. Please, do it from user point of view.