Unsupported provider

classification
Title: msvc9compiler.py: ValueError when trying to compile with VC Express
Type: behavior Stage: patch review
Components: Distutils, Windows Versions: Python 3.5, Python 3.4, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Borisd13, BreamoreBoy, Daniel.Ozminkowski, Frankie.Jhou, Victor.Lin, anuj0990, bgale, eric.araujo, giampaolo.rodola, ipatrol, jafo, jfoo, lemburg, loewis, lwteng, mdengler, mike.mazurek, piotr.dobrogost, sayap, schmir, shimizukawa, srid, steve.dower, tarek, thorsten.behrens, tim.golden, zach.ware, zzzeek
Priority: critical Keywords: patch

Created on 2009-12-15 06:27 by srid, last changed 2014-08-18 20:30 by steve.dower.

Files
File name Uploaded Description Edit
vcvars.diff skrah, 2009-12-16 11:57
vcvars2.diff skrah, 2009-12-19 16:32 Fix vcvars* paths for Visual Studio Express
vcvars3.diff skrah, 2010-07-11 20:49
vcvars4.diff skrah, 2010-07-12 08:26
msvccompiler9_33.diff steve.dower, 2013-04-09 20:39 Replaces query_vcvarsall() for VC9 and VC10 review
msvccompiler9_27.diff steve.dower, 2013-04-09 20:40 Replaces query_vcvarsall() for VC9 and VC10 (Py2.7) review
Messages (76)
msg96422 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-12-15 06:27
Win XP 64-bit
Python 2.6.4 64-bit

Getting distribution for 'pycrypto>=1.9'.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 1714, in main

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 1695, in with_ei_usage

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 1718, in <lambda>

  File "C:\Python26\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 236, in run

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 452, in easy_install

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 501, in install_item

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 680, in install_eggs

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 957, in build_and_install

  File "build\bdist.win-amd64\egg\setuptools\command\easy_install.py", 
line 946, in run_setup

  File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 29, in 
run_setup
  File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 70, in 
run
  File "build\bdist.win-amd64\egg\setuptools\sandbox.py", line 31, in 
<lambda>
  File "setup.py", line 163, in <module>

  File "C:\Python26\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "build\bdist.win-amd64\egg\setuptools\command\bdist_egg.py", line 
174, in run
  File "build\bdist.win-amd64\egg\setuptools\command\bdist_egg.py", line 
161, in call_command
  File "C:\Python26\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "build\bdist.win-amd64\egg\setuptools\command\install_lib.py", 
line 20, in run
  File "C:\Python26\lib\distutils\command\install_lib.py", line 113, in 
build
    self.run_command('build_ext')
  File "C:\Python26\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "C:\Python26\lib\distutils\command\build_ext.py", line 340, in 
run
    self.build_extensions()
  File "setup.py", line 116, in build_extensions

  File "C:\Python26\lib\distutils\command\build_ext.py", line 449, in 
build_extensions
    self.build_extension(ext)
  File "C:\Python26\lib\distutils\command\build_ext.py", line 499, in 
build_extension
    depends=ext.depends)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 448, in 
compile
    self.initialize()
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 358, in 
initialize
    vc_env = query_vcvarsall(VERSION, plat_spec)
  File "C:\Python26\lib\distutils\msvc9compiler.py", line 274, in 
query_vcvarsall
    raise ValueError(str(list(result.keys())))
ValueError: [u'path']
An error occured when trying to install pycrypto 2.0.1. Look above this 
message for any errors that were output by easy_
install.
While:
  Installing python.
  Getting distribution for 'pycrypto>=1.9'.
Error: Couldn't install: pycrypto 2.0.1
msg96425 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-12-15 06:39
Most likely, the problem is that visual studio is not installed on your
system.
msg96426 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-12-15 06:42
I have Visual C++ 2008 express edition installed.

Maybe it is a quirk of express edition as I was able to install pycrypto 
fine with the Visual Studio 2008 professional edition at work machine.

In any case, I believe this is a bug with distutils.
msg96430 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2009-12-15 11:16
I have the same issue with the Express edition. You can work around it
by finding and executing vcvars32.bat or vcvars64.bat before running
setup.py. It would be nice if distutils took care of it though.
msg96432 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-12-15 11:28
That's what distutils does : it runs vcvarsall.bat and pass as the
argument the architecture.

Can you run:

$ vcvarsall.bat arch

(replace arch by x86 or x64)

and paste me the result ?  (it looks like the 'path' variable misses
from this file.
msg96483 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2009-12-16 11:57
I think we have two issues here:

First, the default install of VS Express does not support 64-bit tools,
so distutils cannot work with a 64-bit Python install. I verified that
it _does_ work with a 32-bit Python install.


Second, it is possible to install 64-bit tools from the SDK
(See:http://www.mathworks.com/support/solutions/en/data/1-6IJJ3L/index.html?solution=1-6IJJ3L),
but then some paths are broken in the vcvarsall.bat script:

The script is looking for bin\amd64\vcvarsamd64.bat, the actual path is
bin\vcvarsamd64.bat. The attached diff solves the problem for me, but
someone should verify that the paths are indeed broken when doing the
SDK install as described above.
msg96516 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2009-12-17 14:53
I needed a new Windows VM image anyway, so I can now confirm that the
paths of a fresh VS Express + SDK 64-bit tools install are broken as
described above.
msg96575 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-12-18 19:08
OK so bin\vcvars64.bat would be an alternative location to look at for
win32-64.

Your diff says "amd64", shouldn't it be testing for "x86_64", "amd64"
and "x64" ?
msg96611 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2009-12-19 16:32
Ok, I created a new diff that considers all 64-bit values for 'arch'.
I think x64 cannot occur (See: PLAT_TO_VCVARS). Also, I use the
existence of bin\amd64\vcvarsamd64.bat as a test for VS Professional,
so in that case the new code is never executed.

Could someone confirm that VS Professional always has that file?
msg96613 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2009-12-19 16:37
'ValueError' should be 'DistutilsPlatformError' in the diff.
msg103018 - (view) Author: Christopher Paolini (Christopher.Paolini) Date: 2010-04-13 07:01
I'm running into the same issue myself. I even installed Visual Studio 2008. Issue is it installed as a 32-bit application in the x86 directory, not sure why. I have 64-bit Windows 7. I'm installing the SDK to see if that helps.

Also I need this for pycrypto too. If anyone has a 64-bit AMD build for the latest crypto that'd be amazing.
msg104399 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-04-28 02:13
Tarek, when you set the resolution to 'accepted', did you mean to close this? Resolutions are meant for closed issues.
msg104486 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-04-29 11:56
Some committers have been using 'resolution: accepted' as a way to mark issues that are definitely going to be fixed/enhancement added.  For a critical bug I think this is a bit redundant (it is more useful for feature requests), but I'm pretty sure Tarek did it on purpose.
msg104493 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2010-04-29 12:37
Yes I used 'accepted' to mark this issue as something I am working on.

I am confused about the resolution flag, I think it is a bit overlapping with the status flag, and overcomplex. 

Maybe we should replace "closed" with various flags like: "fixed", "wontfix",  "rejected". (My 2 cents of course ;) )
msg106420 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2010-05-25 09:06
Remarks with the patch:

- we need to keep the find_vcvarsall() backward compatible. e.g. define a default value for arch.

- Next, since this fix is specific to 64bt and since *any value* in arch will be used as "not 64 bits", I think the patch should be using a boolean tag instead (vs64bits=False).

- Last, we need a unit test that runs exclusively in this environment, to demonstrate that youyr fix fixes the error.

Let me know if you want to work on the patch, or I can fix it directly.
I'd prefer of course if you modify the patch ;)
msg106467 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-05-25 19:08
I agree with all points. Could you fix it directly if at all possible?
Of course eventually I'd do it, it might take some time until I get
around to it though.
msg110013 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-11 14:20
Closed issue 9224 as a duplicate of this one;  merging nosy lists.
msg110042 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-07-11 20:39
I've been looking at this again because of new duplicate reports.


I think we need to distinguish between amd64 and x86_amd64/x86_ia64.
But using arch="x86" as the default parameter would do fine.


Re unit test:

The test will only work if 64-bit tools from the SDK are present, and
I'm not sure how to test for that other than writing an independent
find_vcvarsall2 function that checks on the first one.

I have to say that I'm using Linux 99.9% of the time, so perhaps
a Windows expert could suggest a registry based solution.
msg110044 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-07-11 20:49
New version of the patch with a default value for arch.
msg110054 - (view) Author: (ipatrol) Date: 2010-07-11 22:42
May I request we resolve this by folding this patch into the main source tree for the next bugfix release?
msg110055 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-07-11 22:46
ipatrol: have you actually tested the patch? If so, which specific version, and on what specific Python version?
msg110060 - (view) Author: (ipatrol) Date: 2010-07-12 00:36
Actually, I forgot the 64 bit directions X-? It will take some time for everything to download. But I did apply the patch and it did give me the "64 bit SDK not installed" error. Also, I think the tow ValueErrors should be changed to DistutilsPlatformError and DistutilsExecError respectively.
msg110074 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-07-12 08:26
ipatrol, thanks, I forgot to change ValueError. New patch attached.
msg110247 - (view) Author: (ipatrol) Date: 2010-07-14 01:03
Aren't there two ValueErrors in the file? One is a platform and (in the now-fixed version) the other would indicate a problem with I/O or vcvars execution (like permissions).
msg110647 - (view) Author: (ipatrol) Date: 2010-07-18 14:06
I noticed that the directions from mathworks are no longer correct. The only optional feature is a 64 bit SQL server. Yet I still can't get it to work correctly. Does MS no longer provide the compiler in their free editions?
msg110649 - (view) Author: (ipatrol) Date: 2010-07-18 14:10
HAHA DISREGARD THAT, WRONG DOWNLOAD. However, the C++ compiler `is` now installed by default. P.S: that second ValueError?
msg114419 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-08-20 02:43
Stefan (sorry for the misattribution in my previous message), can you test with 3.2 and 3.1 and adjust versions if needed?
msg115226 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-08-30 16:13
> Stefan (sorry for the misattribution in my previous message), can you test with 3.2 and 3.1 and adjust versions if needed?

Not easily at the moment. I just noticed that I replaced my only
Express installation with a Pro trial-edition.

Anyone else?
msg117558 - (view) Author: Ryan Seto (MrWerewolf) Date: 2010-09-28 22:28
I came across this issue while trying to install mercurial using easy_install. I applied the vcvars4.diff to my distutils and this solved the problem.


Environment:

Python 2.6.6 (64 bit)

setuptools-0.6c11.tar.gz
installed using the following instructions:
http://stackoverflow.com/questions/309412/how-to-setup-setuptools-for-python-2-6-on-windows

pywin32-214.win-amd64-py2.6 (installed binaries)
py2exe-0.6.9.win64-py2.6.amd64 (installed binaries)


Windows 7 (64 bit)
Visual Studio Team System 2008 (installed everything)
Visual Studio 2008 SDK 1.1 (installed everything)
msg124526 - (view) Author: Thorsten Behrens (thorsten.behrens) Date: 2010-12-23 01:27
I can test this for 3.1, as all I have is the Express version of VC++. If you could point me towards a library that will work with 3.1 and has C components, that'll make the testing a lot easier. pycrypto and setuptools, the two libs mentioned in this issue, do not support Python 3.x.
msg124543 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-12-23 10:45
Before anyone does any further testing:

Tarek, can this go into distutils 2.7/3.2 (after 3.2 has been released)?
Due to the popularity of this issue I think it might be worthwhile to
make an exception and ignore the distutils freeze.
msg124553 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-23 13:43
IIUC, the issue is that people installing a 64-bit Python, and VS Express, and then wonder why they can't build extension modules. I'm not so sure that there is a bug in Python here - this setup is not supported (and that's really Microsoft's fault). Now, automatically finding the SDK would be a new feature, IMO: if you want to use SDK tools, you are supposed to set DISTUTILS_USE_SDK, after opening the respective build environment. IIUC, installing VS express would not have been necessary in this setup at all - just install the SDK.

Alternatively, people can install Visual Studio proper, or use a 32-bit Python.
msg124556 - (view) Author: Thorsten Behrens (thorsten.behrens) Date: 2010-12-23 15:33
You are right, this is not a bug in Python. The diff provides a workaround for a limitation in VC++ 2008 Express. This diff is a piece of user service.

An equally as workable workaround is for the user to copy VC\bin\vcvars64.bat into VC\bin\amd64\vcvarsamd64.bat. Once that is done, distutils works without the workaround provided in this diff.

Whether to provide a workaround within Python for an issue in VC++ 2008 Express can certainly be debated. I for one suggest to err on the side of being friendly, rather than insisting on purity.

Consider that users of Python do include hobbyists and students. For them, VC++ Pro may be out of reach. And there are plenty of reasons for building 64-bit binaries, among them learning exercises.
msg124563 - (view) Author: (ipatrol) Date: 2010-12-23 18:36
Purity shmurity. The point of distutils is largely to present a unified and simple interface. 'python setup.py install' should be all a user has to do on any platform. Unless you can come up with a better idea, MSVC is really the only big compiler on Windows.
msg124851 - (view) Author: Thorsten Behrens (thorsten.behrens) Date: 2010-12-29 14:41
Confirmed that this issue exists on Python 3.1 and 3.2b2. The exception thrown presents as:

ValueError: ['path', 'include', 'lib']
msg125799 - (view) Author: (ipatrol) Date: 2011-01-08 20:55
Going through more than a few registry keys, here are some that stood out for me:

"HKEY_CURRENT_USER\Software\Microsoft\Microsoft SDKs\Windows\v6.0A" InstallationFolder

"HKEY_CURRENT_USER\Software\Microsoft\Microsoft SDKs\Windows\v6.1" InstallationFolder

"HKEY_CURRENT_USER\Software\Microsoft\VCExpress\9.0\External Tools" ToolDir1

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A" InstallationFolder

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.1" InstallationFolder

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VC7" 9.0

"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows" CurrentInstallFolder

"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VC" ProductDir

"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VC7" 9.0


Maybe they can be read to tease out the install dirs?
msg137703 - (view) Author: mike bayer (zzzeek) Date: 2011-06-05 15:40
regarding "hey this is an MS bug not Python", projects which feature optional C extensions are starting to apply workarounds for the issue on their end (I will need to commit a specific catch for this to SQLAlchemy) - users need to install our software and we need to detect compilation failures as a sign to move on without it.   I think it's preferable for Python distutils to work around an MS issue rather than N projects having to work around an MS issue exposed through distutils.  Seems like this bug has been out there a real long time...bump ?
msg137748 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-06-06 16:11
Thorsten Behrens said:
> You are right, this is not a bug in Python. The diff provides a
> workaround for a limitation in VC++ 2008 Express. This diff is a
> piece of user service.

ipatrol added:
> Purity shmurity. The point of distutils is largely to present a
> unified and simple interface. 'python setup.py install' should be all
> a user has to do on any platform. Unless you can come up with a
> better idea, MSVC is really the only big compiler on Windows.

The feature freeze is distutils is not a conspiracy plotted by developers loving purity; it is a necessity caused by hard pragmatism.  Tarek would have loved to continue improving distutils instead of forking distutils2, but he could not because third-party code relying on bugs and workarounds was broken.  We have to be cautious, and it has nothing to do with purity.  Believe me, the freeze, fork and merge was not something fun for distutils developers, but we had to do it precisely for our users.

While I agree that in an ideal world, “'python setup.py install' should be all a user has to do on any platform”, it cannot be done in distutils.  Like Martin said:
> if you want to use SDK tools, you are supposed to set
> DISTUTILS_USE_SDK, after opening the respective build environment

For distutils2/packaging however, we can work on improving the compiler system, so that “pysetup run install” is all a user had to do on any platform.  See #12257 for that.
msg137750 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2011-06-06 16:36
Hmm, in http://bugs.python.org/issue7511#msg106420 Tarek appeared to
be supportive of the patch.


Re DISTUTILS_USE_SDK:

I don't think many users are aware of this variable. Also, it is not
needed at all; it is sufficient to execute vcvars64.bat manually
before running setup.py.
msg137771 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2011-06-06 19:52
mike bayer wrote:
> > 
> > mike bayer <mike_mp@zzzcomputing.com> added the comment:
> > 
> > regarding "hey this is an MS bug not Python", projects which feature optional C extensions are starting to apply workarounds for the issue on their end (I will need to commit a specific catch for this to SQLAlchemy) - users need to install our software and we need to detect compilation failures as a sign to move on without it.   I think it's preferable for Python distutils to work around an MS issue rather than N projects having to work around an MS issue exposed through distutils.  Seems like this bug has been out there a real long time...bump ?
This is not really an MS issue. Setting up the environment to be
able to compile extensions is a prerequisite on most platforms and
with most compilers.

MS VC++ supports having multiple compiler versions on the same
machine and allow compiling to x86, x64 and ia64 (at least
in more recent VC++ versions).

I think it's fair to ask the user to setup the environment correctly
before running "python setup.py install", since distutils doesn't
really know which compiler to use - e.g. you could be cross-compiling
for x64 on an x86 machine, or you may want to use VC 2008 instead of
a more recently installed VC 2010.

Wouldn't it be better to have distutils tell the user about the
possible options, instead of guessing and then possibly compiling
extensions which later on don't import or import, but don't work
as expected ?

Regarding the latest patch: This is not the right approach, since
find_vcvarsall() is supposed to return the path to the vcvarsall.bat
file and not an architecture specific setup file. It is later
called with the arch identifier, which the arch specific setup files
don't check or use.

Also note that vcvarsall.bat can take these options:

   x86 (default), x64, amd64, x86_amd64, ia64, x86_ia64

The x86_* options setup the cross compilers.
msg137776 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2011-06-06 20:44
Marc-Andre Lemburg <report@bugs.python.org> wrote:
> Wouldn't it be better to have distutils tell the user about the
> possible options, instead of guessing and then possibly compiling
> extensions which later on don't import or import, but don't work
> as expected ?

That would be an option, yes.


> Regarding the latest patch: This is not the right approach, since
> find_vcvarsall() is supposed to return the path to the vcvarsall.bat
> file and not an architecture specific setup file. It is later
> called with the arch identifier, which the arch specific setup files
> don't check or use.

The patch does not change anything for Visual Studio Pro. In Visual Studio
Express (+SDK) vcvarsall.bat is broken, so the architecture specific setup
files have to be used (they also work with a superfluous parameter).


> Also note that vcvarsall.bat can take these options:
>
>    x86 (default), x64, amd64, x86_amd64, ia64, x86_ia64
>
> The x86_* options setup the cross compilers.

I think the patch covers all architecture specific files that are
present in the Visual Studio Express + SDK setup.

Visual Studio Pro is protected from all changes by checking for
the presence of the file bin\amd64\vcvarsamd64.bat. This
could probably be done more elegantly by using some obscure
registry value.



As Thorsten mentioned, another option would be to copy bin\vcvars64.bat
to bin\amd64\vcvarsamd64.bat if the latter is not present.

This is harmless, but it is perhaps not really the business of Python
to mess with existing installs.
msg137777 - (view) Author: mike bayer (zzzeek) Date: 2011-06-06 21:04
> I think it's fair to ask the user to setup the environment correctly
before running "python setup.py install"

We're supporting automatic fallback to non-C install for those environments that don't support it.   We're just looking for a predictable CCompilerError to be raised for conditions like this rather than a ValueError where we have to parse the string message.
msg137779 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2011-06-06 21:11
Stefan Krah wrote:
> > 
> > Stefan Krah <stefan-usenet@bytereef.org> added the comment:
> > 
> > Marc-Andre Lemburg <report@bugs.python.org> wrote:
>> >> Wouldn't it be better to have distutils tell the user about the
>> >> possible options, instead of guessing and then possibly compiling
>> >> extensions which later on don't import or import, but don't work
>> >> as expected ?
> > 
> > That would be an option, yes.
> > 
> > 
>> >> Regarding the latest patch: This is not the right approach, since
>> >> find_vcvarsall() is supposed to return the path to the vcvarsall.bat
>> >> file and not an architecture specific setup file. It is later
>> >> called with the arch identifier, which the arch specific setup files
>> >> don't check or use.
> > 
> > The patch does not change anything for Visual Studio Pro. In Visual Studio
> > Express (+SDK) vcvarsall.bat is broken, so the architecture specific setup
> > files have to be used (they also work with a superfluous parameter).

I guess what I wanted to say is that find_vcvarsall() should
return None for VC Express and code using it should then
revert to using a new find_vcvars() function, which takes the
architecture as parameter and returns the path to the correct
architecture setup file.

Hacking the support into find_vcvarsall() is not the right
approach. You have to add this support one level further up.

>> >> Also note that vcvarsall.bat can take these options:
>> >>
>> >>    x86 (default), x64, amd64, x86_amd64, ia64, x86_ia64
>> >>
>> >> The x86_* options setup the cross compilers.
> > 
> > I think the patch covers all architecture specific files that are
> > present in the Visual Studio Express + SDK setup.

Right, but it doesn't cover the ones available in VS Pro (see
above), which it should for completeness.

> > Visual Studio Pro is protected from all changes by checking for
> > the presence of the file bin\amd64\vcvarsamd64.bat. This
> > could probably be done more elegantly by using some obscure
> > registry value.
> > 
> > 
> > 
> > As Thorsten mentioned, another option would be to copy bin\vcvars64.bat
> > to bin\amd64\vcvarsamd64.bat if the latter is not present.
> > 
> > This is harmless, but it is perhaps not really the business of Python
> > to mess with existing installs.

Not a good idea :-)

PS: Changing the title, since I keep getting the following error messages from the email interface:

There were problems handling your subject line argument list:
- not of form [arg=value,value,...;arg=value,value,...]

Subject was: "Re: [issue7511] msvc9compiler.py: ValueError: [u'path']"
msg137881 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2011-06-07 19:59
Marc-Andre Lemburg <report@bugs.python.org> wrote:
> >> >> Regarding the latest patch: This is not the right approach, since
> >> >> find_vcvarsall() is supposed to return the path to the vcvarsall.bat
> >> >> file and not an architecture specific setup file. It is later
> >> >> called with the arch identifier, which the arch specific setup files
> >> >> don't check or use.
> > > 
> > > The patch does not change anything for Visual Studio Pro. In Visual Studio
> > > Express (+SDK) vcvarsall.bat is broken, so the architecture specific setup
> > > files have to be used (they also work with a superfluous parameter).
> 
> I guess what I wanted to say is that find_vcvarsall() should
> return None for VC Express and code using it should then
> revert to using a new find_vcvars() function, which takes the
> architecture as parameter and returns the path to the correct
> architecture setup file.
> 
> Hacking the support into find_vcvarsall() is not the right
> approach. You have to add this support one level further up.

I agree that it is nicer if find_vcvarsall() actually returns vcvarsall.
The next level though is query_vcvarsall(), so it would still be wrong
to query vcvars64 in that function.

So unless query_vcvarsall() is renamed to something neutral like set_vcvars(),
I'm not sure where to add the support. But I imagine that renaming is out of
the question.
msg138181 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-06-11 18:38
> Hmm, in http://bugs.python.org/issue7511#msg106420 Tarek appeared to
> be supportive of the patch.

I believe Martin has more knowledge about Windows.
msg155557 - (view) Author: Sean Reifschneider (jafo) * (Python committer) Date: 2012-03-13 02:06
Martin: They are looking for you to review this, in particular see:

http://bugs.python.org/issue7511#msg106420
msg156974 - (view) Author: Victor Lin (Victor.Lin) Date: 2012-03-28 06:54
My environment is Windows 7 64bits with VC++ 2008 Express and Python2.7.2.

I encountered same problem, I have tried all solution posted here, but non of them work.

Eventually, I add "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin" to my PATH and it works.

It appears that the command 

    "vcvarsall.bat" x86 & set

outputs different values depending on whether "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin" in PATH.
msg156985 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-03-28 16:01
Victor, can you apply this patch and report that it works. In particular, if it does *not* work, can you please report the exact way of failing? (if you can, please also try to investigate why it fails).
msg156993 - (view) Author: Victor Lin (Victor.Lin) Date: 2012-03-28 17:42
Oddly, can't reproduce the problem anymore. I try to install win7 on virtual machine, but it works as well. I think the issue might caused by something else... not sure, so strange :S

Will look into detail once I encounter this issue again.
msg158024 - (view) Author: Yap Sok Ann (sayap) Date: 2012-04-11 11:52
On 64-bit Windows with Visual Studio 2008 Professional, I also need to apply vcvars4.diff to avoid getting the ValueError. Is this something to be expected?
msg161086 - (view) Author: Piotr Dobrogost (piotr.dobrogost) Date: 2012-05-18 21:59
Just bumped into this issue when installing gevent 1.0b2 on Vista 64bit using pip. I think it would be worth to mention that although I'm not quite new to Python and in the past I already investigated issue with distutils not finding vcvarsall.bat (http://stackoverflow.com/a/5122521/95735), I didn't remember about DISTUTILS_USE_SDK environment variable. What I'm trying to say is that there are probably more people like me, having Visual Studio 2008 Express + Windows SDK installed but not knowing distutils. After seeing that Windows SDK installs 64bit compiler into VC\bin folder of Visual Studio's installation I thought that Python would pick it up automatically the same way it does with non Express versions of Visual Studio.
msg173848 - (view) Author: Daniel Oźminkowski (Daniel.Ozminkowski) Date: 2012-10-26 14:21
Python 2.7.3
WinXP Professional 2002 + SP3
Visual Studio C++ Express 2008

I bumped into this error trying to install fabric. One of the installation steps is compiling pycrypto.
After looking into C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\vcvars32.bat I saw:
"%VS90COMNTOOLS%vsvars32.bat"

so I run:
set VS90COMNTOOLS=C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools 
directly before pip install fabric and it compiled successfully. Still need to see if it works.
msg182869 - (view) Author: Takayuki SHIMIZUKAWA (shimizukawa) Date: 2013-02-24 11:44
FYI. I was able to build both 32bit/64bit.

Python 2.7.3 (32bit)
WinXP Professional SP3 (x86)
Visual Studio C++ Express 2008 SP1
Microsoft Windows SDK 2008

invoke Windows SDK's `CMD Shell` and do following:

C:\tmp> setenv /x64 /release
C:\tmp> set libpath=dummy
C:\tmp> python setup.py build --plat-name=win-amd64 build_ext --library_dirs=C:\Python27\libs-amd64

details is here: http://www.freia.jp/taka/blog/python-win32-binary-building-and-x64-cross-compiling-on-32bit-platform/index.html
msg184983 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2013-03-22 16:46
This becomes more of an issue since VC++ 2008 Express is no longer available for download (unless you're an MSDN subscriber), though the compiler itself is still available as part of http://www.microsoft.com/en-us/download/details.aspx?id=3138 (for VC9)

I'll admit I haven't read all the discussion on other issues that relates to this, but I see no reason why the following maps couldn't be tried if vcvarsall.bat is not found. This would at least handle more cases and as far as I can tell is the only realistic option.

VCVARS_TO_WINSDK_BAT = {
    'x86' : 'bin\\vcvars32.bat',
    'amd64' : 'bin\\vcvars64.bat',
    'x86_amd64' : 'bin\\vcvarsx86_amd64.bat',
    'x86_ia64' : 'bin\\vcvarsx86_ia64.bat',
}

VCVARS_TO_VS_BAT = {
    'x86' : 'bin\\vcvars32.bat',
    'amd64' : 'bin\\amd64\\vcvars64.bat',
    'x86_amd64' : 'bin\\x86_amd64\\vcvarsx86_amd64.bat',
    'x86_ia64' : 'bin\\x86_ia64\\vcvarsx86_ia64.bat',
}

I have no idea why, but the SDK installs the batch files into different locations. VCVARS_TO_VS_BAT should be unnecessary, since vcvarsall.bat should always exist in this case, but I see no harm in having more fallback options.

All of these scripts (at least for VC9, VC10 and VC11) will ignore extra arguments.
msg184984 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2013-03-22 16:48
('ignore extra arguments' meaning they could be returned from find_vcvarsall() and nobody will notice. Though it doesn't bother me if the fallback is handled at a higher level.)
msg185016 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2013-03-22 22:42
I've dug deeper into VC10 and things are even worse there - without VS installed I don't think there's any way for distutils to work without completely replacing query_vcvarsall() (or msvc9compiler, for that matter).

I'm willing to write such a replacement, assuming I can get permission from my management. But I'd rather not do it if someone else is already working on it.
msg185043 - (view) Author: Takayuki SHIMIZUKAWA (shimizukawa) Date: 2013-03-23 12:53
Hi Steve,

> This becomes more of an issue since VC++ 2008 Express is no longer available for download (unless you're an MSDN subscriber)

Here: http://www.microsoft.com/en-us/download/details.aspx?id=13276
msg185067 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2013-03-23 15:39
>> This becomes more of an issue since VC++ 2008 Express is no longer available for download (unless you're an MSDN subscriber)
>
> Here: http://www.microsoft.com/en-us/download/details.aspx?id=13276

That's just the service pack and it won't install unless you already have VS installed. There is no way (other than being an MSDN subscriber) to get VS 2008 at this point - I've checked.
msg185079 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2013-03-23 19:45
On 23.03.2013 16:39, Steve Dower wrote:
> 
> Steve Dower added the comment:
> 
>>> This becomes more of an issue since VC++ 2008 Express is no longer available for download (unless you're an MSDN subscriber)
>>
>> Here: http://www.microsoft.com/en-us/download/details.aspx?id=13276
> 
> That's just the service pack and it won't install unless you already have VS installed. There is no way (other than being an MSDN subscriber) to get VS 2008 at this point - I've checked.

There is, but you have to know what to look for :-)

http://download.microsoft.com/download/E/8/E/E8EEB394-7F42-4963-A2D8-29559B738298/VS2008ExpressWithSP1ENUX1504728.iso
msg185094 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2013-03-23 21:33
>> That's just the service pack and it won't install unless you already have VS installed. There is no way (other than being an MSDN subscriber) to get VS 2008 at this point - I've checked.
>
> There is, but you have to know what to look for :-)

Fair enough, but I can't (as a Microsoft employee) endorse that link or guarantee that it won't go away :)

I still think it's worth fixing distutils to look in the right places for VC, since there are multiple ways of installing it that all include different batch files.
msg185096 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2013-03-23 21:35
On 23.03.2013 22:33, Steve Dower wrote:
> 
> Steve Dower added the comment:
> 
>>> That's just the service pack and it won't install unless you already have VS installed. There is no way (other than being an MSDN subscriber) to get VS 2008 at this point - I've checked.
>>
>> There is, but you have to know what to look for :-)
> 
> Fair enough, but I can't (as a Microsoft employee) endorse that link or guarantee that it won't go away :)
> 
> I still think it's worth fixing distutils to look in the right places for VC, since there are multiple ways of installing it that all include different batch files.

Sure, no question about that. Adding support for more MS VC versions
is always a plus :-)
msg186447 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2013-04-09 20:39
I've added a patch that replaces query_vcvarsall() with an implementation that does not try and use the batch file. Instead, the functionality of the batch file (effectively, reading the base path from the registry and appending constants) is reproduced in Python code.

(There is a second patch for 2.7, since winreg/_winreg is different between the two.)

There is no reason to expect that the installation layout of VC9 and VC10 will change at this stage, though future updates may be required for new versions (though I've already added the mapping for VC11 - not that we're building Python with that one yet).

I have left find_vcvarsall() in there, even though it is no longer used, in case other tools are monkeypatching to work around the existing issue.
msg186448 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2013-04-09 20:40
Adding patch for 2.7.
msg192224 - (view) Author: Frankie Jhou (Frankie.Jhou) Date: 2013-07-03 09:06
Microsoft using Visual Studio 2012 (VC 11.0) now,
Errors happened again. 
I just want to install Cython.........

Error: Unable to find vcvarsall.bat
ValueError: [u'path', u'include', u'lib']
NameError: name 'KEY_BASE' is not defined
KeyError: '9.0'
error: command 'cl.exe' failed: No such file or directory
msg192692 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2013-07-08 20:20
I must have missed something when I merged files to create the diffs. In any case, you'll still require VC9 or VC10 to be able to build something compatible with a CPython release (though maybe that doesn't matter for Cython? I don't know).

When I get a chance I'll fix up the changes and then ping Python-Dev about getting a review.
msg194030 - (view) Author: Bill Gale (bgale) Date: 2013-08-01 01:11
so i hit the same exception, here is how i solved it.

environment:
windows 7 enterprise 64 bit
python 2.7.5 64 bit
visual studio 2008 32 bit

issue:
pip installs failed with the above exception.

solution:
there are two parts.
1. install 64 bit components to vs2008
2. modify the PATH to point to 64 bit vs2008 bin folder

to confirm is this solution will help you:
check if there is an amd64 under your vs2008 bin folder:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin
if yes, this solution will not help you.
if missing follow the steps below.

step 1.
control panel
select Microsoft Visual Studio 2008 Professional -ENU
window Visual Studio 2008 Maintenance Mode is opened
click through to and select Add or Remove Features
Under Language Tools->VC++ "X64 Compilers and Tools" should be unchecked.
if it is checked, skip to step 2.
check "X64 Compilers and Tools", Update.
you may have to provide the VS2008 installation CD.
confirm that update creates bin\amd64 subfolder.

step 2.
add 64 bit subfolder to your path.
VS2008_HOME=C:\Program Files (x86)\Microsoft Visual Studio 9.0
PATH=%PATH%;%VS2008_HOME%\VC\bin;%VS2008_HOME%\VC\bin\amd64;
open new command window to receive new PATH changes.
pip installations should no die with the ValueError.
msg196929 - (view) Author: Li Wah Teng (lwteng) Date: 2013-09-04 17:47
About the "'KEY_BASE' is not defined" error in Steve Dower's diff, I was able to fix it by adding the following line before the KEY_BASE variable is referenced:

KEY_BASE = r"Software\Microsoft\\"

With this, I was finally able to use the patched msvccompiler9.py to build PyCrypto using VS Express 2010 with Windows SDK 7.1 and Python 3.3.2 (64-bit) installed.

If someone can confirm that this is the only thing missing in the 2 versions of the msvccompiler9.diff files, it would be great.

Hope it helps!
msg197076 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2013-09-06 15:04
I believe that is all that is missing from the patches I posted, though I'd have thought that having Visual C++ 2010 Express installed would be sufficient without the patch (though you didn't mention C++, so maybe you have a different one?).
msg205835 - (view) Author: Justin Foo (jfoo) * Date: 2013-12-10 16:28
The speedups extension for MarkupSafe (which has a pure Python fallback) on Python 3.3.3 64-bit was happily compiled with `pip install markupsafe` after applying Steve's patch and Li Wah's definition for KEY_BASE.
msg212023 - (view) Author: (ipatrol) Date: 2014-02-23 19:19
The latest patch has an indentation error in an if-else clause, but I can't figure out what exactly was intended by the author.
msg212030 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2014-02-23 21:29
Steve: Why are you providing a Python 3.3 patch? AFAICT, the issue does not exist with VS 2010 (express).
msg212039 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-02-23 22:57
My patches (which I've backed away from now - between wheels and monkey patching Distutils from a setup.py, there are enough workarounds) also handled the fact that VS 2008 is no longer freely/officially available, and presumably VS 2010 will eventually go the same way. From my point of view, VC++ 2008 Express not including 64-bit compilers is less of a concern than VC++ 2008 Express not being available at all.

The Windows SDK is the only way that VC9 is distributed now, but it doesn't install the vcvarsall.bat file that Distutils needs. The same goes for the version of the SDK that includes VC10. These patches look in the registry for the actual paths, rather than just to find a batch file that isn't a component of the compiler.

(FWIW, the patches should be identical apart from some Python 2/3 differences - the version number is parameterised.)
msg212213 - (view) Author: Justin Foo (jfoo) * Date: 2014-02-25 21:10
I think getting this bug fixed would be really nice from a user experience point of view.

I've further into this for my own setup, which is Python 3.3 64-bit, Visual C++ Express 2010 and the Windows SDK v7.1 (plus service packs), which is probably a typical setup for a user looking to build Python extensions without paying for a compiler. Here's what I've noticed, apart from the fact that msvccompiler9.py is a mess.

query_vcvarsall executes "vcvarsall.bat amd64 & set". The first part, trying to delegate to another batch file that doesn't exist, will fail. So no environment variables will be set, but the PATH environment variable always exists, hence "ValueError: ['path']".

The DISTUTILS_USE_SDK environment variable is useless, even leaving aside the fact that MsSdk also needs to be defined. The idea is that distutils will trust that the user has set the appropriate environment variables (e.g. SetEnv.Cmd /Release). However, successful compilation of 64-bit extensions won't rely on this variable at all:

1. DISTUTILS_USE_SDK/MsSdk defined, SetEnv not called: "cl.exe" and friends can't be resolved and nothing works.

2. DISTUTILS_USE_SDK/MsSdk defined, SetEnv called: "cl.exe" and friends can be resolved and everything works.

3. DISTUTILS_USE_SDK/MsSdk undefined, SetEnv not called: "vcvarsall.bat amd64" will fail and we end up with "ValueError: ['path']" as above.

4. DISTUTILS_USE_SDK/MsSdk undefined, SetEnv called: in query_vcvarsall, "vcvarsall.bat amd64" still fails, but it doesn't matter at this point, because the environment variables INCLUDE, LIB, LIBPATH and PATH will exist, so parsing "vcvarsall.bat amd64 & set" works. This doesn't guarantee linking with the correct bitness, but one would hope so :)


I believe SetEnv.Cmd can be found using HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDKTools or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDKTools.
msg217017 - (view) Author: Mike Mazurek (mike.mazurek) Date: 2014-04-22 19:30
In building pycrypto for python 3.4 I applied patch msvccompiler9_33.diff. After applying the patch there is an unassigned variable: KEY_BASE on line 67 of the patched file. 
After setting
KEY_BASE = "Software\\Wow6432Node\\Microsoft\\"
before its first use I was able to successfully build pycrypto.
msg225506 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-08-18 20:15
I'm assuming that the 2.7 patch is still valid but have no idea whether or not any work is needed on 3.4 or 3.5.
msg225507 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-08-18 20:30
There is other work going on that will make the patches unnecessary. One problem is that vcvarsall.bat isn't where msvc9compiler.py is looking, which can be fixed with monkey patching in setup.py or in setuptools. The other problem is that VC9 is hard to get hold of these days. I'm working on both problems and dealing with the big-company-inertia problem.

For 3.5 I'll update msvc9compiler.py as part of my VC14 support. 3.4 (and 3.5 in the meantime) don't need to be updated as the easiest way to get VC10 is still as part of VS 2010. However, when the VS 2010 download is removed then things will become more difficult.

In general, I think we're better off helping package developers make builds/wheels than we are helping users to get the compiler. Windows just doesn't have enough platform incompatibilities to make it worthwhile.
History
Date User Action Args
2014-08-18 20:30:16steve.dowersetmessages: + msg225507
2014-08-18 20:16:06brian.curtinsetnosy: - brian.curtin
2014-08-18 20:15:36BreamoreBoysetnosy: + BreamoreBoy, zach.ware

messages: + msg225506
versions: + Python 3.5, - Python 3.2, Python 3.3
2014-06-23 14:49:33Borisd13setnosy: + Borisd13
2014-05-13 22:25:35skrahsetnosy: - skrah
2014-04-28 22:09:16pitrousetnosy: + tim.golden, brian.curtin
2014-04-25 09:37:12skrahlinkissue21348 superseder
2014-04-22 19:30:36mike.mazureksetnosy: + mike.mazurek
messages: + msg217017
2014-02-26 20:19:43ned.deilysetmessages: - msg212255
2014-02-26 14:13:52anuj0990setnosy: + anuj0990
messages: + msg212255
2014-02-25 21:10:59jfoosetmessages: + msg212213
versions: + Python 3.4
2014-02-23 22:57:14steve.dowersetmessages: + msg212039
2014-02-23 21:29:54loewissetmessages: + msg212030
2014-02-23 21:20:09loewissetassignee: loewis ->
2014-02-23 19:19:51ipatrolsetmessages: + msg212023
2013-12-10 16:28:54jfoosetnosy: + jfoo
messages: + msg205835
2013-11-25 10:11:40mdenglersetnosy: + mdengler
2013-09-06 15:04:10steve.dowersetmessages: + msg197076
2013-09-04 17:47:08lwtengsetnosy: + lwteng
messages: + msg196929
2013-08-01 01:11:51bgalesetnosy: + bgale
messages: + msg194030
2013-07-08 20:20:41steve.dowersetmessages: + msg192692
2013-07-03 09:06:04Frankie.Jhousetnosy: + Frankie.Jhou
messages: + msg192224
2013-04-09 20:40:10steve.dowersetfiles: + msvccompiler9_27.diff

messages: + msg186448
2013-04-09 20:39:38steve.dowersetfiles: + msvccompiler9_33.diff

messages: + msg186447
2013-03-23 21:35:59lemburgsetmessages: + msg185096
2013-03-23 21:33:24steve.dowersetmessages: + msg185094
2013-03-23 19:45:02lemburgsetmessages: + msg185079
2013-03-23 15:39:03steve.dowersetmessages: + msg185067
2013-03-23 12:53:16shimizukawasetmessages: + msg185043
2013-03-22 22:42:59steve.dowersetmessages: + msg185016
2013-03-22 16:48:33steve.dowersetmessages: + msg184984
2013-03-22 16:46:50steve.dowersetnosy: + steve.dower
messages: + msg184983
2013-02-24 11:44:52shimizukawasetnosy: + shimizukawa
messages: + msg182869
2012-10-26 14:21:33Daniel.Ozminkowskisetnosy: + Daniel.Ozminkowski
messages: + msg173848
2012-05-18 21:59:44piotr.dobrogostsetnosy: + piotr.dobrogost
messages: + msg161086
2012-04-20 17:53:51mark.dickinsonsetnosy: - mark.dickinson
2012-04-11 11:52:35sayapsetnosy: + sayap
messages: + msg158024
2012-03-28 17:42:13Victor.Linsetmessages: + msg156993
2012-03-28 16:01:18loewissetmessages: + msg156985
2012-03-28 06:54:05Victor.Linsetnosy: + Victor.Lin
messages: + msg156974
2012-03-13 02:06:54jafosetassignee: tarek -> loewis

messages: + msg155557
nosy: + jafo
2011-06-11 18:38:07eric.araujosetmessages: + msg138181
2011-06-07 20:05:27r.david.murraysetnosy: - r.david.murray
2011-06-07 19:59:38skrahsetmessages: + msg137881
2011-06-06 21:11:16lemburgsetmessages: + msg137779
title: msvc9compiler.py: ValueError: [u'path'] -> msvc9compiler.py: ValueError when trying to compile with VC Express
2011-06-06 21:04:39zzzeeksetmessages: + msg137777
2011-06-06 20:44:04skrahsetmessages: + msg137776
2011-06-06 19:55:45MrWerewolfsetnosy: - MrWerewolf
2011-06-06 19:52:28lemburgsetnosy: + lemburg
messages: + msg137771
2011-06-06 16:36:44skrahsetmessages: + msg137750
2011-06-06 16:11:16eric.araujosetmessages: + msg137748
2011-06-05 15:40:54zzzeeksetnosy: + zzzeek
messages: + msg137703
2011-02-10 11:03:55schmirsetnosy: + schmir
2011-01-08 20:55:28ipatrolsetnosy: loewis, mark.dickinson, giampaolo.rodola, tarek, eric.araujo, r.david.murray, srid, skrah, ipatrol, MrWerewolf, thorsten.behrens
messages: + msg125799
2010-12-29 14:41:24thorsten.behrenssetnosy: loewis, mark.dickinson, giampaolo.rodola, tarek, eric.araujo, r.david.murray, srid, skrah, ipatrol, MrWerewolf, thorsten.behrens
messages: + msg124851
2010-12-23 18:36:59ipatrolsetnosy: loewis, mark.dickinson, giampaolo.rodola, tarek, eric.araujo, r.david.murray, srid, skrah, ipatrol, MrWerewolf, thorsten.behrens
messages: + msg124563
versions: + Python 3.2, Python 3.3
2010-12-23 15:33:22thorsten.behrenssetnosy: loewis, mark.dickinson, giampaolo.rodola, tarek, eric.araujo, r.david.murray, srid, skrah, ipatrol, MrWerewolf, thorsten.behrens
messages: + msg124556
2010-12-23 13:43:28loewissetnosy: loewis, mark.dickinson, giampaolo.rodola, tarek, eric.araujo, r.david.murray, srid, skrah, ipatrol, MrWerewolf, thorsten.behrens
messages: + msg124553
2010-12-23 10:45:00skrahsetnosy: loewis, mark.dickinson, giampaolo.rodola, tarek, eric.araujo, r.david.murray, srid, skrah, ipatrol, MrWerewolf, thorsten.behrens
messages: + msg124543
2010-12-23 01:27:38thorsten.behrenssetnosy: + thorsten.behrens
messages: + msg124526
2010-10-02 16:53:42giampaolo.rodolasetnosy: + giampaolo.rodola
2010-09-28 22:28:32MrWerewolfsetnosy: + MrWerewolf
messages: + msg117558
2010-08-30 16:13:59skrahsetmessages: + msg115226
2010-08-30 15:30:13skrahlinkissue7546 dependencies
2010-08-20 02:43:57eric.araujosetmessages: + msg114419
2010-08-20 02:40:58eric.araujosetmessages: - msg113641
2010-08-11 23:22:52Christopher.Paolinisetnosy: - Christopher.Paolini
2010-08-11 23:17:25eric.araujosetnosy: + eric.araujo

messages: + msg113641
versions: - Python 2.6
2010-07-18 14:10:09ipatrolsetmessages: + msg110649
2010-07-18 14:06:10ipatrolsetmessages: + msg110647
2010-07-14 01:03:03ipatrolsetmessages: + msg110247
2010-07-12 08:26:45skrahsetfiles: + vcvars4.diff

messages: + msg110074
2010-07-12 00:36:13ipatrolsetmessages: + msg110060
2010-07-11 22:46:59loewissetmessages: + msg110055
2010-07-11 22:42:29ipatrolsetnosy: loewis, mark.dickinson, tarek, r.david.murray, srid, skrah, ipatrol, Christopher.Paolini
messages: + msg110054
components: + Windows
2010-07-11 20:50:27skrahsetfiles: - vcvars3.diff
2010-07-11 20:50:01skrahsetmessages: - msg110043
2010-07-11 20:49:50skrahsetfiles: + vcvars3.diff

messages: + msg110044
2010-07-11 20:49:36skrahsetfiles: + vcvars3.diff

messages: + msg110043
2010-07-11 20:39:47skrahsetmessages: + msg110042
2010-07-11 19:50:58sridsetversions: + Python 2.7
2010-07-11 14:20:00mark.dickinsonsetnosy: + mark.dickinson, ipatrol
messages: + msg110013
2010-07-11 14:19:12mark.dickinsonlinkissue9224 superseder
2010-07-07 12:49:19skrahlinkissue9187 superseder
2010-06-19 21:36:09georg.brandllinkissue5969 superseder
2010-05-25 19:08:37skrahsetmessages: + msg106467
2010-05-25 16:55:56terry.reedysetnosy: - terry.reedy
2010-05-25 09:06:06tareksetmessages: + msg106420
2010-04-29 12:37:09tareksetresolution: accepted ->
messages: + msg104493
2010-04-29 11:56:16r.david.murraysetnosy: + r.david.murray

messages: + msg104486
stage: patch review
2010-04-28 02:13:15terry.reedysetnosy: + terry.reedy
messages: + msg104399
2010-04-13 07:01:50Christopher.Paolinisetnosy: + Christopher.Paolini
messages: + msg103018
2010-02-02 23:22:31tareksetpriority: critical
resolution: accepted
2009-12-19 16:37:08skrahsetmessages: + msg96613
2009-12-19 16:32:38skrahsetfiles: + vcvars2.diff

messages: + msg96611
2009-12-18 19:08:41tareksetmessages: + msg96575
2009-12-17 14:53:58skrahsetmessages: + msg96516
2009-12-16 11:57:04skrahsetfiles: + vcvars.diff
keywords: + patch
messages: + msg96483
2009-12-15 11:28:30tareksetmessages: + msg96432
2009-12-15 11:16:56skrahsetnosy: + skrah
messages: + msg96430
2009-12-15 06:42:14sridsetmessages: + msg96426
2009-12-15 06:39:10loewissetnosy: + loewis
messages: + msg96425
2009-12-15 06:27:52sridcreate