On Sep 6, 2015 10:28 PM, "Andrew Barnert via Python-ideas" <python-ideas@python.org> wrote:
>
> On Sep 6, 2015, at 21:20, Donald Stufft <donald@stufft.io> wrote:
> >
> > Let's take lxml for
> > example which binds against libxml2. It needs built on Windows, it needs built
> > on OSX, it needs built on various Linux distributions in order to cover the
> > spread of just the common cases.
>
> IIRC, Apple included ancient versions (even at the time) of libxml2 up to around 10.7, and at one point they even included one of the broken 2.7.x versions. So a build farm building for 10.6+ (which I think is what python.org builds still target?) is going to build against an ancient libxml2, meaning some features of lxml2 will be disabled, and others may even be broken. Even if I'm remembering wrong about Apple, I'm sure there are linux distros with similar issues.
>
> Fortunately, lxml has a built-in option (triggered by an env variable) for dealing with this, by downloading the source, building a local copy of the libs, and statically linking them into lxml, but that means you need some way for a package to specify env variables to be set on the build server. And can you expect most libraries with similar issues to do the same?

Yes, you can! :-)

I mean, not everyone will necessarily use it, but adding code like

if "PYPI_BUILD_SERVER" in os.environ:
    do_static_link = True

to your setup.py is *wayyyy* easier than buying an OS X machine and maintaining it and doing manual builds at every release. Or finding a volunteer who has an OS X box and nagging them at every release and dealing with trust hassles.

And there are a lot of packages out there that just have some cython files in them for speedups with no external dependencies, or whatever. A build farm wouldn't have to be perfect to be extremely useful.

-n