This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author db3l
Recipients db3l, jeremy.kloth, jkloth, miss-islington, pablogsal, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2018-12-11.02:12:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1544494325.31.0.788709270274.issue35433@psf.upfronthosting.co.za>
In-reply-to
Content
Hmm, VS2015 started as a full installation (with UI), probably right from its initial release.  The build tools only installation (v141) is for VS2017.

Best I can tell I'm at update 1 - my update version in the registry is 14.0.24720 (plus I have a .1 installer still in the filesystem).  Not sure why I don't have 10586 if that came with update 1.  But I wouldn't be surprised if I'm no further.  The last time I used the VS2015 installer it completely messed up one of my workers and took a bunch of time to recover from.

When switching to VS2017 I think I thought it was going to be preferred for the 3.x series when available, so I probably treated the VS2015 version as less critical.  I guess that didn't end up happening for earlier than 3.7.

Anyway, best next steps to close out this issue...

I assume my installing any matching SDK (say 15063) would allow the workers to match the build script.  Alternatively, including more recent SDKs (16299 is the next in line) in the build script would work with the existing workers.  I'm fine either way.
History
Date User Action Args
2018-12-11 02:12:05db3lsetrecipients: + db3l, paul.moore, vstinner, tim.golden, jkloth, jeremy.kloth, zach.ware, steve.dower, pablogsal, miss-islington
2018-12-11 02:12:05db3lsetmessageid: <1544494325.31.0.788709270274.issue35433@psf.upfronthosting.co.za>
2018-12-11 02:12:05db3llinkissue35433 messages
2018-12-11 02:12:04db3lcreate