distutils as of Python 2.7.9 is unable to locate vcvarsall.bat if Visual C++ Compiler for Python is the only Visual Studio "distribution" installed.
STR:
1) Do a fresh install of Windows + all updates
2) Install Microsoft Visual C++ Compiler for Python from http://www.microsoft.com/en-us/download/details.aspx?id=44266
3) Enter a Visual C++ 2008 command prompt via start menu
4) Attempt to run any |python.exe setup.py| that contains C extensions
5) "Unable to find vcvarsall.bat"
Examining the behavior of MSVC for Python's bat scripts and filesystem layout, it is different enough from "full" "distributions" that it confused distutils.
First, MSVC for Python doesn't appear to set any meaningful registry entries. So, the registry checking in msvc9compiler fails to find anything.
Second, the command environment for MSVC for Python doesn't export VS90COMNTOOLS, so msvc9compiler has no clue where to go looking for files.
Third, even if VS90COMNTOOLS is set, msvc9compiler isn't able to find vcvarsall.bat because it is installed in %installdir%/vcvarsall.bat and not %installdir%/VC/vcvarsall.bat, unlike every other Visual Studio AFAICT.
Another concern is that distutils.msvc9compiler.find_vcvarsall() first attempts to read from the registry, not the environment. If you are in a MSVC for Python command shell and you also have Visual Studio 2008 installed, distutils will use vcvarsall.bat from the full Visual Studio installation instead of the Python one. I think this is wrong.
The MSVC for Python command prompt does have an environment variable that can be used: VCINSTALLDIR. It is set to %installdir%\VC\, which is equivalent to ~/AppData/Local/Programs/Common/Microsoft/Visual C++ for Python/9.0/VC/ if you launch the installer with default options. distutils could be patched to find vcvarsall.bat in %VCINSTALLDIR%\..\vcvarsall.bat
Fortunately, a workaround is available:
1) Enter MSVC for Python command prompt
2) SET DISTUTILS_USE_SDK=1
3) SET MSSdk=1
4) python.exe setup.py ...

The first sentence in my original report is ambiguous. I tested with distutils on Python 2.7.9. But considering the code in question hasn't changed since 2011, I think it's safe to say this isn't a regression in CPython.

Setuptools has the code to find the compiler package. We deliberately put it there instead of in distutils to make sure more people would get it.
I should probably port the extra check into 2.7.10, but the immediate fix is to import setuptools.

Thanks, Steve.
The package I was trying to build has its setup.py importing "setup" from distutils, not setuptools. I'll see about porting them to the future.
For posterity, https://bitbucket.org/pypa/setuptools/issue/258, which was first released in setuptools 6.0.

FWIW, at some point I will need to do some serious work on this code for Python 3.5, so I'll certainly take your suggestions into account there. But I won't be doing the same for old versions of Python - at most 2.7 may get a check for the extra registry key, but 2.6 and 3.0-3.2 will still need to be using setuptools>=6.0 (which 2.7.10 will ship with).
Also, pip forces setuptools onto packages whether they like it or not, so pip installs should always build. Because it's a monkeypatch, "import setuptools" is sufficient to port old setup.py files.
All together, there doesn't seem to be an urgent need to get this into the core release. If someone comes up with a simple patch I'll happily review and apply it (and Jason will want a setuptools patch to skip the monkeypatch there), but I need to spend my own dev time on the next release.

Is there anyway to fix this without using setuptools? I'm using distutils to compile on the fly which has worked brilliantly for the last few years, not sure I want to destabilize everything by switching to setuptools.

Thanks! However, importing setuptools causes a string of errors about PYTHONPATH and .pth files (even on a linux system)
In addition, a monkeypatched version of find_vcvarsall allowed things to run, but it seems finding plain C libraries with Visual C++ for python is very different from finding libraries in mingw
I think I'll just start telling my windows users to install MinGW instead

Python does not support being built with MinGW, but we have "support" to build extensions with MinGW. It isn't great support, and we're open to patches/contributions (none of our core Windows devs use MinGW AFAIK).
And yes, VC is different from MinGW because MinGW is trying to copy a different operating system. Where possible, Python generally tries to follow the conventions of the underlying operating system, which is why we build with VC and not gcc on Windows.

You could also distribute wheels for your Windows users, which they will appreciate much more than being told to install MinGW. (If you do go the latter route, WinPython is a pretty good distribution that sets that stuff up fairly transparently.)

Hard to be sure. It was my contribution originally, and I'm okay to remain unattributed, but I've nosied Jason so he can answer authoritatively (especially since he rewrote most of my original contribution to make it work better :) ).

That's two separate questions:
> Is it possible to get the license issues resolved
AFAICT they are resolved. Go ahead and copy the relevant code from setuptools.
> get this fixed in 2.7.11
Why do you need/want to build without setuptools?

Ok, I was confused since the ticket was still marked as Open. We are trying to make an open source CPython extension available for download and building and we don't want to add a dependency on setuptools. We will patch our build commands based on the setuptools link provided in the message above.

I'm back on this issue with a minimal patch, and a longer motivation.
Distutils does not support Visual C++ for Python compiler, but it could, with a one-line patch.
The proposed workaround is to use `setuptools`. But, we are not alone in this World, am I supposed to fork each third party package still using `distutils` and upgrade them to `setuptools`?
No, someone will say, you can "simply" `import setuptools`, and it will monkey-patch `distutils` adding the support for VS for Python.
1) this is implicit, very very against the Python Zen
2) the modifications are not limited and back-compatible. Some packages, say `sip` from `PyQt`, are broken simply adding this `import setuptools`, and other are too.
That said, I think this minimal patch to the `find_vcvarsall` code, can save a lot of time to every Python 2.7 users, time I see better spent upgrading to Python 3.
Sorry for the rant-mode, but I very liked Python, and I still like Python more than other languages, but I don't think that providing half broken solutions and very limited support to all the developer still running Python 2.7 in some big old project is a good strategy to push people to Python 3.
Python 3 is already a better language, but Python as a language can be a better language only if Python 2.7 will be a first class citizen till 2020.