Does `pip install lxml` fail in a similarly perplexing way if you don't have `build-essential` (`gcc` et al) installed? If so maybe the difference is that the posix/linux crowd is more likely to have installed a compiler at this point.
Here's hoping MSFT's Linux ABI support evolves into the norm for a port target.
compilation terminated.
*********************************************************************************
Could not find function xmlCheckVersion in library libxml2. Is libxml2 installed?
*********************************************************************************
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
----------------------------------------
Cleaning up...
Command /usr/bin/python -c "import setuptools, tokenize;__file__='/tmp/pip_build_test/lxml/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-QEyvN6-record/install-record.txt --single-version-externally-managed --compile failed with error code 1 in /tmp/pip_build_test/lxml
Storing debug log for failure in /home/test/.pip/pip.log
In the opposite case, say that I have the compiler installed, but not the dev package for the library. Compiling an object will fail, if it #includes a required header, but that will be in the form of a "file not found" error emitted by the compiler. Similarly, if I tried to link a program and include the "-lxml2" flag, the linker will reply "cannot find -lxml2", meaning that libxml2 isn't installed, so it can't be linked against.
Generally, we'd say that it's not the compiler or linker's job to talk to the package manager. The build configuration system included with the project (autoconf scripts, cmake or ant profiles, etc) ought to check for prerequisites.
The long running issue with Windows was that there weren't any compilers available (AFAIK) outside of installing Visual Studio first. When Visual Studio started offering free versions, the problem persisted: it's rather hard to justify downloading and installing a +4gb program just to make an dependency or extension to work (even if it wasn't directly required for the said dep).
For example, this was a huge issue with node-gyp[1], which prompted Microsoft to release standalone Build Tools[2] to alleviate the problem. I think it's the same kind of issue with Python here, right?
[1] https://github.com/nodejs/node-gyp/issues/629 [2] https://www.microsoft.com/en-us/download/details.aspx?id=499...
If MS was really serious about Python being a first class citizen on Windows then fix the root problem which the post acknowledges, ".... Because Windows has a different culture, most people do not have (or need) a compiler." Why doesn't Visual C++ express come installed or as a super easy to install dependency on Windows? Howabout MS pushing to change the culture of Windows to one where compiling from source isn't a big deal and is as easy as it is on Linux?
Also it's super helpful that this post lays out where to find precompiled versions of Python packages for Windows, but again it's something if MS were really serious about they would step up their game significantly. Why is it that some random person, Christoph Gohlke (and as a side note many thanks to them, they have undoubtedly helped thousands of people), is the maintainer of one of the most important resources for Python users on Windows? How about MS steps up and dedicates resources to ensuring precompiled and tested python binary packages are available for all packages?
Finally I think the message that people should bug Python library owners to get windows wheels up is very poor advice. Library maintainers have enough to deal with and piling on more frivolous issues won't help. What if the maintainers don't even have Windows machines to build binary packages with (and again, why doesn't MS step up to provide them with said Windows machines/licenses)? Badgering the maintainers isn't going to make things better. If MS is serious about python on Windows they need to step up their support and make the platform better.
Why doesn't Visual C++ express come installed or as a
super easy to install dependency on Windows?
A Windows feature that installed the matching C++ compiler plus platform SDK would be freaking AWESOME.
as a side note many thanks to them
By the way MS provides free official VMs for testing IE but work just fine for building wheels.
If none of these options is available, you will need
to consider building the extension yourself. In many
cases this is not difficult...
I spent a few weeks at the beginning of the year building MSIs for SaltStack and its dependencies, as I wanted a fully native way to bootstrap a Windows client installation via GPO using a native Python installation instead of SaltStack's NSIS executable installer, which uses an esky build. In short:
* The compiler included in Microsoft Visual C++ Compiler for Python 2.7 is not compatible with distutils.
* The compiler included in version 7.0 of the Microsoft Windows SDK is not compatible with distutils.
* The compiler included in version 7.1 of the Windows SDK is not compatible with Python, nor is it compatible with distutils.
The only combination of compiler plus SDK that I could get to work properly was Visual Studio 2008 and Windows SDK 7.1, and that still didn't work quite right due to bugs in the code underlying bdist_msi, source distributions not including everything used to actually build a given package, incorrect package build instructions, and so forth. (For example, I seriously doubt that the pywin32 developers even follow their own package build instructions.)
In case you're curious:
https://gist.github.com/xenophonf/c2351f8af80d3231b547
Ultimately, I've given up and switched back to SaltStack's executable installer, run out of a computer startup script (a page out of my own book on 90s-era NetWare sysadmin, yuck).
Python was compiled by Visual Studio 2008, up until Python 3.5, and I believe that was made clear in the extension module documentation for python.
Having used 3.5 and VS2015 (after waiting for multiple days just for VS to finish installing), everything else has worked pretty spiffy since
The extension module documentation, including this blog post, says to use Microsoft Visual C++ Compiler for Python 2.7. I couldn't get it to work properly, and I tried the other toolchains after quite a bit of research, a word which here means "reading through the Python source code and trying various search terms in a vain attempt to solve a problem that apparently isn't a problem for anyone else, but they can't be bothered to specify their obviously functional build environments in sufficient detail for me, an expert in the art, to recreate in a clean virtual machine here at home". It was only after this little endeavour of mine that I came to appreciate people's work on reproducible builds, Vagrant, etc.
And you aren't kidding about that VS2015 install taking forever and a day. Updates are almost as bad.
That said, I think MS can/should make installing a toolchain easier than they do. It ought to just be another component of the OS that you can choose to have or not have. Supporting different versions of the compiler on one box is a more advanced use-case that advanced developers can deal with - but each rev of the OS should have the "default" toolchain that installs seamlessly.
It's also part of the reason why I ultimately switched to Mac.