{{This post is a bit of a blast from the past, being somewhat historical. Well, I can’t change the publication date like I could in Drupal (I won’t go into the reasons I quit using Drupal just now) so it gets bumped up to 2017…}}

When Python moved to the ‘pip’ installer system, I was torn about it. On one hand, it sounded like a great idea – package management! Great! But so far I’ve spent a fair bit of time grumbling over its oddities and annoyances.

Trying to install Numpy, it just wouldn’t do it. It would always fail with, while not the most useless error message in the world (that is reserved for the wonderful “Error: no error”) one that could have been quite a bit less cryptic.

I recognise the file it’s talking about, because it’s part of Visual Studio.

It’s interesting that it’s complaining, because I have Visual Studio 2013 Community installed, and am slowly learning that… (shock)… I quite like it. But the issue is that Python 3.4 was compiled using Visual Studio 2010. And looks for vcvarsall.bat in one place and one place only.

Anyway, there are several options, most of which are simply unacceptable in my view.

“The internet” seems to think that installing Visual C++ 2010 Express, when I already have VS2013 installed is a sensible, (nay, essential!) thing to do. I disagree. So I refused to do it.

The next “internet suggestion” was install MinGW and point pip to it as a compiler. OK, but I’ve got a compiler already, I want to use that. While my dev environments tend to have a lot in them, I don’t need a Swiss Army Knife with 1001 tools – just a few will do me, thanks.

The second was use pre-compiled binaries. OK, I’ve done it before with things like PyMol – let me just take this opportunity to plug Christoph Gohlke’s superb collection – but it has to be possible to do this myself…

To that end, you can just do the following:

Create an Environment Variable for “VS100COMNTOOLS” (Visual Studio 2010 is version 10.0) which points at the same directory as “VS120COMNTOOLS”

Which works perfectly.