On 25May2016 1229, Chris Barker wrote: > Hi folks, > > The standard build of Py3.5 for Windows is built with VS2015 (correct??) > And it includes the runtime dlls it needs. > > However, we've found that wxPython wheels for win32 (not sure about > win64) also need: > > MSVCP140.DLL There are two different versions of this DLL for each architecture (same name). > So: wxPython could include that of course, But it looks like it's > getting included with the Matplotlib wheels already (so folks with > Matplotlib can run wx....). I'm just guessing, but this looks like the > standard run time for C++ with that compiler. > > Python itself doesn't use C++, of course, but maybe we should include > that dll with Python anyway -- that way folks can build wheels of > packages with C++ extensions in the normal way, and those wheels will > "just work", and we don't have to have every individual package ship the > same dll. Unfortunately, it won't "just work". More often than not, it will break in weird and very difficult to diagnose ways, as the version of msvcp140.dll changes on a regular basis (there are at least four different version of it "in the wild" since VS 2015 released, not counting the preview releases before mid-last year). Importantly, it will break forward compatibility. We are already on the hook to keep shipping vcruntime140.dll for all 3.5 (and probably 3.6) releases, and if binary packages are built with later versions of VS then they'll need to include a (hypothetical) vcruntime150.dll (which distutils will already do, because I added that functionality). Other than that, every dependency of Python 3.5+ is forwards-compatible with new operating systems and compilers. There's also a slippery slope argument that would legitimately justify shipping all sorts of "common" dependencies with the core product. I chose to draw the line at "needed by the core Python product", rather than "created by Microsoft" or "used by many packages". (Hence vcruntime140.dll is included, despite not having forwards-compatibility, and I tried real hard to avoid including that one too.) Finally, unless we demand users are administrators for every install, we will quickly have many Python installs using versions of msvcp140.dll (or any other dependency) with security vulnerabilities, with no way to update them other than a full Python release. Installing the regular runtime (which is patched automatically) or as part of a package (which can be independently updated) is far more feasible. I really don't want to be doing security updates for 15 years just to keep an unused DLL secure. Hopefully that helps explain the position somewhat. I'm happy to go into more detail on any of these issues if anyone would like (potentially just linking to where I've previously discussed it either here, on bugs.p.o or on my blog). Cheers, Steve
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4